Automatically set role name as tag

[robinro]

Proposal: Automatically set role name as tag

Author: Robin Roth <@robinro>

Date: 2016/06/13

• Status: New
• Proposal type: core
• Targeted Release: 2.4
• Associated PR: Automatically set role name as tag ansible#25132 Please autotag roles with the role name ansible#17434
• Estimated time to implement: done

Motivation

A common theme is to use the role name also as a tag, e.g.

roles:
  - { role: webserver, tags: [ 'webserver' ] }

With this patch one can instead write

roles:
  - webserver

and have the same result.

Problems

At the moment it's common to repeat the role name in tags. Following DRY this should not be the case.

Solution proposal

See PR ansible/ansible#25132

Testing (optional)

Should be tested. Can be added to the tags test coverage.

Documentation (optional)

Needs to be documented in playbooks_roles.

Possible Drawbacks

This change could lead to unwanted behavior in existing playbooks if a tag is used with the same name as a role AND the role is not tagged with that tag. This usage is rare in my experience and not enough to outweigh the benefits imo.
To mitigate the issue one could have a config setting to toggle this feature and default it to the old behavior.

Alternatives

Add a CLI option --role to ansible-playbook, which limits execution to a specific role in parallel to --tags.

[robinro]

This idea is originally from @agx

@bcoca in the PR called this

I find this a bit too 'magical' also it might collide with existing tags.

In the core meeting on 2016-06-13 several people agreed with the general idea and suggested to open this proposal.

[geerlingguy]

+1 to doing this—maybe to avoid the potential collision, we could make it opt-in? E.g. an ansible.cfg flag like role_name_as_tag: False that's disabled by default, and then at some point in the future it would be enabled by default?

[azaghal]

How about having role tags with slightly different naming, for example role:database_server. This way it would be clear what you really want to run, and should reduce chance of collisions.

Another thing I would like to point out is maybe some discussion should be made on whether meta deps should be included or not when specifying tag like this. I could easily see that in some cases you just want to run role tasks without meta deps (especially when developing the role), while in other you might want to call the full thing (together with deps). Not sure how this would be handled syntax-wise, though.

[robinro]

I updated the PR to include the config flag suggested by @geerlingguy. Having this off by default allows people to check for collisions manually and switch it on if they like it. We can then review later whether the default should be True.

[bcoca]

Expanding on my previous point, this also affects the exiting tagged/untagged tags .. i really don't want to create an 'autotagged' one. There is also the interaction with include role, which is not static as roles:, it can get very complicated there.

One big issue is that roles also can easily have characters that are not 'valid/legal' for tags, tags need to be 'valid dictionary keys' while role names need to be 'valid filesystem names'. This is easy to solve technically but then you enter the realm of tags not being what the user expected and/or overlapping with other tags.

As for the --role CLI option ... it would be simpler to enable include_role to work with Adhoc mode, it doesn't really seem to make any sense to make it an option of the ansible-plabyook command. Includes don't currently work due to their dual nature (static/dynamic) but that is changing in 2.4.

To the suggestion above, PLEASE don't give yet another special meaning to : there are other characters to abuse.

As for the global flag ... it will also require a keyword directive as people will want to turn on/off by play/block/role. At this point I think that adding a tag entry is about as much work with a lot less magic, less code, less fuss.

Also mentioned above are dependencies .... things really start to get complicated now.

I understand that this is a nice convenience, I just think it adds a lot of complication for a tiny benefit for a particular workflow. As such -1

[geerlingguy]

I understand that this is a nice convenience, I just think it adds a lot of complication for a tiny benefit for a particular workflow. As such -1

In agreement there—in my case, I've never added a [rolename] tag for each task in a role, because I'd rather my users add a tag in the playbook if they really need to just run one role:

- hosts: all
  roles:
    - role: geerlingguy.apache
      tags: ['apache']

Having tags set on a playbook/integration level means that the tags are actually meaningful. And if you have roles that are complex enough that you have to have different tags for different portions of the role... IMHO that role should be broken up so each role focuses on one smaller thing.

[bcoca]

@geerlingguy I don't disagree with 'smaller more focused roles' but I'm not partial to prevent people from doing otherwise, sometimes there is a good reason .. other times it is not optimal, but we should not be imposing workflow where possible.

[bcoca]

closing as per above