I’m not sure how to gracefully do this programmatically in AWX where this is would need to be parsed, and I’m not sure that ansible-config is even available in that context.
try 2.17, I have been improving the output in 2.16 and 2.17 (more complete and more target-able). Also working on adding ‘galaxy servers’ right now (which were left out as they are dynamically generated config)
ansible-config is available in the EE as it is part of the ansible cli, so AWX can test the validity of things for that EE
NO_COLOR is a ‘standard’ variable for those that need screen readers, its alias to ANSIBLE_NOCOLOR and would be generally outside the ANSIBLE_ restriction.
_ANSIBLE_ prefix also exists, these are variables used internally for testing config. We also have _ansible_ vars that are also exclusively internal to core and should not be in use by any plugins (though modules can/should read them when received, AnsibleModule does this by default).
I meant it would be nice if they could comment specifically in regard to populating a blacklist of ANSIBLE_ environment variables to validate custom credential types against, rather than the ANSIBLE_ prefix itself. And whether or not this would need to be a static list or if it can be generated programmatically from ansible-config on the fly from a control_node’s EE (considering the awx image itself doesn’t have ansible installed as far as I’m aware).
Turns out our mirror wasn’t stale, I just didn’t realize that python3.9 support was dropped in ansible-core>=2.16.
Here’s the environment vars from 2.17, and there doesn’t appear to be any “alternate” values as there were in 2.14. Used the same powershell snippet from above.
I have a funny feeling that the new credential plugin architecture won’t have this issue. Even if it still does this for “custom credential types” in the UI, you could just go create a named plugin instead. How we go about adding 3rd party plugins is another matter. It may need to be added to the official credential plugins repo until some other installable method becomes available.
While this thread has several ideas of how to improve the situation, there has never been any feedback from the AWX team. I’m really not sure how to continue, except maybe suggesting users to stop using AWX if they encounter this problem.
Is it possible to make any progress here, or is this a lost cause?
(And I really should have included this in my CfgMgmtCamp list, I guess I forgot since there was no activity for years, while the underlying problem is still there and hurting users.)
There are modules for which the underlying backend, be it a CLI command or a Python library, has its own env vars. Some modules use those vars as fallback to parameters and it really makes sense, since they are using the same vars and content that the would be used otherwise. It makes no sense IMHO to force these modules to prefix all their vars with ANSIBLE_ across all collections in the fold.
I much prefer the approach taken by Molecule, in which the docs (last I read and not lazily checking now) state that env vars named MOLECULE_xxx are reserved for Molecule itself and should not be used by anyone else.
If, and that’s a very humongous if, we really want to force a prefix on the vars, my suggestion would be for: each collection should take their pick. The only thing we can do is enforce this at the collections’ CI, ensuring the consistency within that domain. Even then, we might want to have exception cases.
These modules were never required to ues the ANSIBLE_ prefix, and I don’t think anyone is suggesting that they should use it.
I think there should be at least a guideline for how these should look like. And they really should start with ANSIBLE_ IMO, since they are about configuring Ansible collections, and Ansible roles and Ansible playbooks using these, and not random other software that has nothing to do with Ansible.
Well, IMO there is a philosophical conundrum here: whilst we may choose to see things from that perspective you present, I would argue that most of them are not about Ansible but rather they are about the thing we are using Ansible to configure. Ansible is (mostly) a means to an end, not the end itself.
Moreover, there is this old principle from Software Engineering where we should group things by their functional cohesion, and though naming vars is not exactly the same thing, with some indulgence that principle could be used here. For full disclosure, I cheated with the LLM to remember its name and logic : https://share.gemini.google/GpvkEO8LaE5n
(And I do break that principle sometimes, because it is very easy to group by logical cohesion, so it takes some self-policing to abide by it).
Both statements about the ANSiBLE_ prefix are not in conflict, the first is about core authored plugins/modules, which are not going to have 3rd party libraries or APIs, and then a subsequent related decision in the AWX project.
The second statement is about restrictions to the modules/plugins in general. If this had been made a requirement, it would have been enforced in the code, if not the runtime (ConfigManager), at least in the validation (validate-modules), as it is done for many other requirements.
I don’t see a problem here. All environment variables defined by plugins or modules should use the ANSIBLE_ prefix, unless there are common environment variables for the ecosystem these plugins/modules are about that the modules/plugins are using in the same way than other members of the ecosystem. This is how I understand the discussion from back then, and the excerpt in the issue the discussion was about.
Since back then, all development happened inside ansible/ansible and thus inside the ansible package, I can see that some people interpret the discussion and the excerpt differently by focussing on ansible-core, but I don’t think my interpretation (and it wasn’t only mine) is any less valid than the other interpretation.