Complicating this, our inventory comes from one project and is shared with many other projects. We want to disable some warnings that come from our inventory, which requires settings in ansible.cfg. But each project would have to carry those settings as Ansible is executed within the context of that project, not of the project where the inventory source comes from.
I fear that this will result in needing to keep many project repos in sync with a base ansible.cfg.
Am I off base here? What are people doing to manage this in the real world?
We want to disable some warnings that come from our inventory, which requires settings in ansible.cfg. But each project would have to carry those settings as Ansible is executed within the context of that project, not of the project where the inventory source comes from.
Yes, this is a valid point for Ansible CLI use. But I don’t see what form this would surface as a problem in AWX. If anything, using AWX might solve this problem for you because inventory is imported and saved to the database separately from playbook runs. So you import your inventory and use it in multiple job templates, and the job runs will use their own project-specific config.
The inventory that’s in AWX has “invalid” group names. So unless the Ansible.cfg disables the warnings there is a lot of scary looking output in the job output. Quelling this output requires an Ansible.cfg in every repo.
The warnings are a minor issue compared to the fact that Ansible core will be making the change in their current release cycle, and your playbooks might stop working at that point. Maybe they won’t break, but then I would bet that Ansible will continue to issue a warning. This does need some solution on the AWX side.
If you care nothing more than making it go away everywhere on your server, then set the env var ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS to silently in the default job environment setting.
Could there not be a way of providing an `ansible.cfg` configuration
from the AWX side? I haven't thought this through, but perhaps an
AWX-wide config that could get overridden by a project-specific
configuration?
That is exactly what the setting for the default job environment allows now. Because it’s environment variables, you have to use the env name of the setting, as opposed to the conf-file-name of the setting. See:
Environment variables allow you to set a single variable with a higher precedence than what’s in the config file, while still using all of the other settings defined in the config file.
As the original email points out, you can’t do anything similar with multiple config files.
AWX sets several config variables due to its integration points.
When this is done, we do try to check if it was set in the environment where AWX is running, or in the default env settings.
Thus, the point here is that even if AWX wants to set a config, it will respect the user’s value at higher precedence, unless it’ll just totally break output or something.
Thanks Alan. Using the global job ENV settings appears to address my concerns, and I’ve removed ansible.cfg files from project repos. I knew there had to be a better way!
