Optional Feature: Controlled tags

[jhawkesworth]

Proposal: Optional Controlled Tags

Add an optional capability to ansible-playbook that would allow a list of acceptable tags to be configured in ansible.cfg and enforced at runtime.

Author: Your Name <@yourGHid> IRC: handle (if different) "Jon hawkesworth": IRC: jhawkesworth_ Date: 2018/07/03

• Status: New
• Proposal type: core design
• Targeted Release: 2.next
• Associated PR: no PR
• Estimated time to implement:

Motivation

Allow teams to adopt standard notions of what function will be performed when running a playbook using tags.

As playbooks grow in length and complexity, tags start to be used by team members. It is up to team members to agree meaning of tags. Having a common set of tag names would allow team members to be more confident about the scope and likely effects of running a playbook with a given tag, without having to examine the playbook in detail.

For example, if ansible.cfg held the following in acceptable_tags: destructive provision configure application status

then tags such as 'conf', 'cfg' or 'fixbug#4778' would be disallowed at runtime and over time team members would come to understand that running anything with 'destructive' is likely to have very high impact on a system, whereas running with 'configure' might only adjust configuration settings, and status might only report on current system status without making any changes.

Problems

What problems exist that this proposal will solve?

1. Control. I have resisted adopting tags as there is no way to define the meaning of a given tag name. Currently I have separate playbooks for creating infrastructure, adding software stack components and updating the in-house written applications that sit on top of the stack.

The higher impact playbooks are isolated from the lower impact ones be being held in a separate directory, but I would rather have fewer playbooks with more ways to run through them to reduce repetition of roles/tasks in separate playbooks.

2. Testing. Having a controlled list of tags would allow me to adopt tags without having to be concerned about having a potentially unlimited number of different ways in which a playbook could be run (which impacts testing positively as it means you limit the total number of ways a playbook needs be run in order to test it).

Solution proposal

Allow 'controlled_tags' to be set in ansible.cfg This would need to be a list of tag names, comma separated.

Modify pre-parsing step of ansible-playbook Since tags are listed when playbooks are run with --list-tasks, tags could be compared with the controlled_tags list during playbook parsing.

Tags encountered during pre-parsing of playbooks which did not match the list of acceptable flags would stop the playbook from executing, and fail with an error message describing which tags were encountered that weren't on the 'controlled_tags' list. Rather than failing on the first encountered non-matching tag, it would preferable to complete parsing and only warn and fail once all tags have been considered.

Dependencies (optional)

No external dependencies.

Testing (optional)

Feature requires testing.
It could however be tested simply using ansible integration tests Does / should this require testing, and if so, how? Describe here. This section is optional but could be helpful.

Documentation (optional)

Feature should be documented along with other settings in ansible.cfg documentation.

[bcoca]

https://docs.ansible.com/ansible/latest/reference_appendices/config.html#tags-run https://docs.ansible.com/ansible/latest/reference_appendices/config.html#tags-skip

[jhawkesworth]

https://docs.ansible.com/ansible/latest/reference_appendices/config.html#tags-run could making testing proposed feature easier.

[bcoca]

i think you can already do what he asks:

[tags]
run=destructive,provision,configure,application,status,untagged

this will, by default, run 'untagged' tasks and those with 'acceptable' tags

[jhawkesworth]

Thanks for this @bcoca

i guess I should try it it, but if there were tags not in the run list, would the tasks be skipped, or the playbook stopped (I'd like the latter)?

[bcoca]

they would be skipped, we dont have a 'stop/error' tag facility

[jhawkesworth]

So to clarify this proposal is to add the ability to stop playbooks from running if tags which are not on an approved list.

I suppose this would add to the time needed to pre-process playbooks on startup.

Dynamic includes could be problematic as its possible tags would not be encountered until tasks are being run at run time. Emitting a warning would be acceptable for me (since I don't use dynamic includes). A possible future enhancement might be to check for dynamic includes and warn/fail if they are encountered.

I think emitting a warning might be the best way to handle unapproved tags encountered at runtime.

[bcoca]

The more i think about this, the more I want to push it to a linter tool and not the ansible runtime.

[jhawkesworth]

@bcoca There hasn't been much (any?) interest from others in this feature, which makes me think it is perhaps motivated by some specific quality of my setup or organization which is rare or even unique.

I think one reason that I draw a distinction between provisioning and configuration is perhaps because most of the targets are windows and the overall execution speed of the playbooks is somewhat slower than against linux hosts to achieve similar goals.

At the time I wrote this I was very much thinking of a runtime/pre-run check but if it were say integrated into ansible-lint that might actually be better as it could catch stray/unapproved/accidental tags as part of continuous integration, so I'm +1 to your suggestion of having it as a linting feature.

[bcoca]

closing as per above