hi Michael,
Just want to check if this is what tags already do. “I want to run this role but only those tasks who have the following tags. That way you don’t need to specify them on the command line.”(Vincent above described exactly what i need). I read your solution below to use multiple roles and using role dependencies but not sure if it apply in this case. I will try to explain my use case.
I have a role, load_balancer. The tasks/main.yml has 3 tasks(check below for details), most of the time, i can assign that WHOLE role to a host. Since it is idempotent everything should just work and it is great. But some time all i really want to do is just update_config of the load_balancer,( i think is why Ansible is different from puppet or chef where a whole playbooks must be run) so in the command line i can run “–tags update_config”. Because every time i want to update the config there are others step i want to do. So i created a playbook that uses this role and other modules.
I named the playbook load_balancer_update_config_only.yml. But for my customers who are using this playbook, i much rather to encapsulated all the logics about the role load_balancer and tags update_config inside the playbook instead.
tasks/main.yml
- include: install_nginx.yml tags=install
- include: update_load_balancers_json.yml tags=update_json,update_config
- include: sync_nginx_config.yml tags=update_config
Hi Xie,
We solved the problems with the yum repos an other way.
Maybe a way to solve this is by using when with your task. You pass a variable with your role and check that with the when clause of your task.
If you for example define your role the following way:
- { role: foo_role, execute: false }
And then in your task you say:
when: execute
Mattias
TL;DR – Expanding the use of tags to include filtering at the playbook or include level could facilitate the iterative nature of playbook and role development while also making roles on ansible-galaxy more widely applicable.
I just stumbled on to this topic with the same need and it seems sort of unresolved. This relates to a basic knot I’ve been running up against with Ansible. That is, the relationship between “roles” and “tags”. I think that depending on what you’re trying to do with Ansible, and to some degree how you perceive your task at hand (are you IT? A developer? Management?), different people have different needs and expectations.
Another knot relates to the progression and maturation of a playbook in to a properly organized role and eventually a set of roles. I found myself describing a new infrastructure project and going through the following steps:
1.) A single playbook that does a few things I want
2.) A single role with everything broken in to task files, templates, etc…
3.) A set of tags to break up rational sets of tasks
4.) The break-up of tagged tasks in to individual roles
But there are sticky parts between each step. As you migrate from one step to the next, you’re having to reorganize; moving tasks in to files, files in to folders, and so-on. It’s often dirty business. As a developer you might want to run it one way, but management wants you to run it another. As an IT person you might want everyone to keep their hands off and it’s all run your way. The need for of-the-moment maneuvering requires both flexibility and rigidity. As both roles and the organization mature, things become more rigid, more folder-oriented, etc. In the meantime, I think tags should be very flexible in their application. I’d like to filter by tag at almost any level, from the command-line, from the playbooks, inside any include statement, etc…
As it is I’ve found most roles on Ansible Galaxy unusable. Roles seems to have an identity crisis–sometimes there’s a role for organizing something as small as PHP, other times something as large as an entire stack. In many cases, I often find that the role doesn’t always fit in to my way of doing things. I think that expanding the breadth of tags to be as flexible as possible would help make things in that ecosystem fit together more gracefully.
“I want to be able to specify what tags I want to be run for a role in the playbook instead of on the command line”
Ok, so this is about selectively including part of a role.
Yeah, we don’t want do that.
What should happen here is you should break the role into smaller parts and leverage role dependencies.
This isn’t a great universal solution. I understand why you might be hesitant about selectively including part of a role, but in reality, a cloud topology may have many interdependencies between them. For example:
I have a nagios role. It installs nagios, apache, a bunch of nagios plugins, and configures it based on members of other groups which come from dynamic inventory. One of my nagios tags is “update_config”. When I provision new nodes from another playbook I want to depend on nagios role and only run the update_config tasks. I can run the others safely, but it takes much longer. Separating update_config to a “nagios_update_config” role seems silly to me. If I continue doing this, I’ll end up with ~5 sub-roles for every 1 role.
Thoughts?