Fully Qualified Tags

Project Discussions
, ,
1

Now that FQCNs are real, it’s reasonable (isn’t it?) to speculate about what else might benefit from being fully qualified. To me, tags are jumping up and down in the back of the room waving both hands shouting, “Pick me! Pick me!” Silly tags. Okay, tags, I’m picking you.

First, a couple of notes about tags.

  • Tags seem to be really useful during playbook and task file development, but production projects and shared roles/collections tend to rely on passed variables to control variant behavior. That assertion is backed by zero actual data; it’s a gut feeling I have based on the way I learned Ansible. If there’s any truth to it, though, I suspect it’s due at least in part to the next note…

  • Tags’ usefulness diminishes with depth. They’re relatively easy to “get right” in the top level playbook, somewhat so in first level included task files if the include itself has an always tag. (Different rules for imports though, so watch out!) In roles you didn’t write, you’ll probably end up applying the tags that got your there in the first place. If those shared tasks even have tags, they’re probably only useful at that depth as --skip-tags. But go search StackOverflow for how to properly use skip tags. We’ll wait; it won’t take long.

But imagine if you could qualify tags. Rather than --tags=foo which would affect all tasks, what if you could say --tags=my_collection.my_role.foo? Such a tag would only affect tasks in that role. So would the unqualified --tags=foo, because the tasks tags: expressions would still be the unqualified strings. It wouldn’t be necessary to change the tags: expressions on the tasks within my_collection.my_role because Ansible already knows the provenance of those tasks, and thus what qualifiers would match their tags

I could see the same thing working for tags (and eventually other things) in “local” (non-collection) roles, although I waffle on how to qualify uncollected roles’ tags. Would --tags=monty.foo be enough to signify the project level monty role, or would --tags=.monty.foo (with a leading “.”) be a better way to explicitly qualify this tag (or anything else that eventually gets the ability to be qualified) as “something local to the project that isn’t in a collection”? The empty bit before the first dot means “project level uncollected thing.” I lean toward the latter just because “two dots implies a qualifier” seems more consistent. But, hey, implement it and prove me wrong!

Those are my thoughts on Fully Qualified Tags. What are yours?

3 Likes