Global fact/variable namespacing idea...

It’s kinda old, but these two comments spell the challenge out nicely. It get’s especially hard when you’re using ansible-galaxy and/or have many roles from many different sources. I’ve had that, and related name-collisions cause massive debugging nightmares.

For example, with external-originating fact from dynamic inventory, cache, or /etc/ansible/facts.d/. Especially for “temporary” facts/buffers that are only required for a few tasks (e.g. the tempfile action). It’s dangerous to use them in your role blindly, and it’s dangerous (for other roles) to always initialize them. Overall, the choices seem to be:

  • Use obnoxiously long names and hope they don’t collide.

  • Use a ridiculous number of assertions.

  • Only call roles with import_role: private=true…

  • Use some sneaky jinja2-magic tricks, writing out yaml, then re-importing it.

  • Overload/recycle a very common name, like “result”, and only ever use it privately.

So far (in my experience) the last option has been the lesser of all the evils, and generally works well, but isn’t very readable. Though I’ve had an idea, that could/maybe solve this problem, and would like feedback:

  1. Extend either set_fact or add a new module that:
  • Allows easily selecting a namespace (just a dictionary or branch) for adding for a new leaf item.
  • Allows easily removing the selected branch/leaf from selected namespace.
  • Allows easily updating a selected branch from a branch in another namespace (dict.)1. Add an always private, static-name, role-namespace (like _private) that only exists within the context of the role.
    I’d like to emphasize the ‘easily’ term here meaning, deliberately non-tricky, simple, and back/forward compatible. It’s not a perfect fix, actual namespaces would be really nice. But maybe this would be enough to give role and play authors a little more control over the chaos? Whatch’y’all think?

Clarification: This is not a feature request, it’s a proposal for one. I’d rather not waste my time working on it if it’s a bad idea or would be terribly difficult to pull off.

I rarely see any answers on this forum, you may get an attention by talking at http://webchat.freenode.net/?channels=ansible-devel instead.

Marcin