idea: invoke tags for roles in role definition

[Mattias Gees]

I think it would be a good idea to make it possible to invoke tags when you define a role in you playbook.
For example we have a yum-repos roles with multiple repository definitions in it. All these repository's are tagged (epel-repo, company-repo, ...). Now we need to add --tags needed-repos when we execute our playbook. I am in favor to add an extra variable like 'with_tags' to the roles definition in the main playbook.

Here is an example:
roles:
- { role: foo, var: 8888, with_tags: [ 'epel_repo', 'company_repo' ] }

With this change I think it is possible to reduce the amount of roles.

Let me now what you think.

Regards,
Mattias

[Vincent Van der Kussen]

Hi,

I also like my colleague's idea because in some cases you don't know (or want to know)  which tags you need for a certain role. so +1 for this.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael DeHaan]

" Now we need to add --tags needed-repos when we execute our playbook."

Actually, that's not quite the case, you need to specify "--tags needed-repos" only when you specify --tags.    If you don't specify --tags, all tags will run, including untagged items.

The solution is to untag the steps that you always need to run every single time.

[Vincent Van der Kussen]

Michael,

I think this is what Mattias means :

In a role you could tag several tasks. In your playbook you could say  : 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.

It would be like  a "collection" of tasks where you can choose from using tags. In this case yum repos.

Vincent

[Michael DeHaan]

Roles do have the capability to tag several tasks:

- { role: foo, tags: [ 'a', 'b'  ] }

Which automatically tags all tasks loaded with a, b, c

Thus if you want to run the role you just say

--tags a

or --tags b

Thus you could establish a convention of just tagging the role with it's role name, if you wanted that.

You *DO* need to specify them on the command line to indicate you want to run certain tags, I don't think you want to get away from that at all.

You do get the tags list when you specify invalid tags so it's easy to browse them if need be.

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Mattias Gees]

Hello Micheal,

The idea we have is to make it also possible to run tags of roles without defining them on the command line, but to make it possible to define which tags need to be run in the playbook definition.
In our case we have a yum-repos role with multiple repository definitions. But not all playbooks need all those yum repositories (sometimes we only need our company repo and in other cases only the epel repo and so on). Instead of needing to remember what repositories every playbook needs and defining it on the command line. It would be useful to define the needed tags in the playbook.

regards
Mattias

[Serge van Ginderachter]

On 2 May 2013 11:35, Mattias Gees <mattia...@gmail.com> wrote:

The idea we have is to make it also possible to run tags of roles without defining them on the command line, but to make it possible to define which tags need to be run in the playbook definition.
In our case we have a yum-repos role with multiple repository definitions. But not all playbooks need all those yum repositories (sometimes we only need our company repo and in other cases only the epel repo and so on). Instead of needing to remember what repositories every playbook needs and defining it on the command line. It would be useful to define the needed tags in the playbook.

​Can't you solve this with conditional or parametrized includes?​

[Michael DeHaan]

"Instead of needing to remember what repositories every playbook needs"

Sounds like those playbooks should just template the repos they need into yum.repos.d to me.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[C. Morgan Hamill]

Excerpts from Mattias Gees's message of 2013-04-30 04:36:50 -0400:

> I think it would be a good idea to make it possible to invoke tags when you
> define a role in you playbook.
> For example we have a yum-repos roles with multiple repository definitions
> in it. All these repository's are tagged (epel-repo, company-repo, ...).
> Now we need to add --tags needed-repos when we execute our playbook. I am
> in favor to add an extra variable like 'with_tags' to the roles definition
> in the main playbook.
>
> Here is an example:
> roles:
> - { role: foo, var: 8888, with_tags: [ 'epel_repo', 'company_repo' ] }

Just to note, because I like this idea too, this will work as-is now:

---
# myplaybook.yaml
- hosts: *
roles:
- { role: myrole, repos: ['epel_repo', 'company_repo'] }
---
# roles/myrole/main.yaml
- include: epel_repo.yaml
when: "'epel_repo' in repos"

# or
- template: src=epel.repo.j2 dest=/etc/yum.repos.d/epel.repo
when: "'epel_repo' in repos"

You could get fancier and have all repos included by default by using:

when: "'epel_repo in repos or repo is not defined"

So on and so forth.
--
Morgan Hamill
<cha...@wesleyan.edu>

[awidde...@hotmail.com]

Sorry to dig up old posts but I was just trying to do this today and found that it wasn't really possible unless I'm missing something which lead me to this thread after some googling. Is this feature not going to happen? I'd obviously like to see it implemented as well.

[awidde...@hotmail.com]

I am trying to do the same thing which brought me to this post. Is this not possible yet? Any plans for it to be implemented? If I were to conjure up a patch would it get accepted? 

[Michael DeHaan]

The previous summary from serve:

" I want to run this role but only those tasks who have the following tags."

This is what tags already do.

I'm confused as to what you want, or think is not there.

On Sat, Oct 19, 2013 at 6:02 PM, <awidde...@hotmail.com> wrote:

I am trying to do the same thing which brought me to this post. Is this not possible yet? Any plans for it to be implemented? If I were to conjure up a patch would it get accepted? 

--

[awidde...@hotmail.com]

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. So to use what I'm doing now as an example, I'm trying to deploy an application that has a server and a client. They share a lot of the same tasks for installation. Servers will get all of the server files including client files while the clients only get the client related files. I didn't want to have to split things up into roles for this because it seemed like unnecessary sprawl. What I ended up doing in the interim which I got the idea from the previous post is just use conditional logic and variables. 

Here is what I put in my playbook:

- {role: application, client_only: true}

Then in my role for tasks that are only required for servers I added:

when: client_only is not defined

Instead of doing this I'd like to just use tags and be able to invoke tags from within the playbook. I understand that you can do it on the command line but some of the other users who use ansible or even myself may forget to add the "client" tag or whatever when they run something. This would help prevent that.

[David Karban]

What about to do a client role and server role and have. Client role will have only what client need and server role will have client role as a dependency and add server specific stuff?

I know you wrote, that you do not separate roles, but I have feeling you are missing role dependencies?

2013/10/20 <awidde...@hotmail.com>

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

David Karban
Specialista na správu linuxových serverů
www.karban.eu

[awidde...@hotmail.com]

I'm sure doing separate client/server roles would work but again, I don't really want to have this role sprawl. Means more files, more directories... just more stuff. To me it is simpler to just keep everything in a single role and just use tags to install what is appropriate.

[Michael DeHaan]

"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.

[Michael DeHaan]

"I know you wrote, that you do not separate roles, but I have feeling you are missing role dependencies?"

http://ansibleworks.com/docs/playbooks_roles.html#role-dependencies

On Sun, Oct 20, 2013 at 11:30 AM, David Karban <da...@karban.eu> wrote:

--

[awidde...@hotmail.com]

Is there anyway when executing a role for it to know that it was invoked as dependency for another role and can it know what the initial role was named?

[Michael DeHaan]

Nope.

[Chaoran Xie]

Hi Vincent,

Did you guys ever find a way 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".  It seems that at one point Michael DeHaan said it below that this is what tags already do but i wasnt able to get it to work. And the suggestion for breaking things into multiple roles and uses dependencies does not really apply to what i want to do.  

[Chaoran Xie]

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

[Mattias Gees]

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:

- command: /bin/something

  when: execute

Mattias

2014-01-31 Chaoran Xie <cx...@hubspot.com>:

To post to this group, send email to ansible...@googlegroups.com.

[Synaesthete]

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.

[Trevor Hartman]

On Sunday, October 20, 2013 at 10:43:30 AM UTC-6, Michael DeHaan wrote:

"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?