TRANSFORM_INVALID_GROUP_CHARS doesn't document valid group patterns

[xarses]

SUMMARY

With the addition of the TRANSFORM_INVALID_GROUP_CHARS. Other than reading the source, it was not clear which characters must be avoided going forward, only that the warning (with -vvvv) points out which characters you currently use that are invalid.

Please clarify that you are pushing the names to be valid python vars. This is missing from the documentation for the cfg option, warning and online documentation

(https://github.com/ansible/ansible/commit/d241794daa6d413e6447890e2a4f11e0d818cf0e#diff-b77962b6b54a830ec373de0602918318R122)

There appears to be no mention of this on https://docs.ansible.com/ansible/latest/porting_guides/porting_guide_2.8.html either.

ISSUE TYPE

• Documentation Report

COMPONENT NAME

group

ANSIBLE VERSION

ansible 2.8.0
  config file = /home/awoodward/ansible-skynet/ansible.cfg
  configured module search path = [u'/home/awoodward/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 2.7.5 (default, Apr  9 2019, 14:30:50) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]

CONFIGURATION

n/a

OS / ENVIRONMENT

n/a

ADDITIONAL INFORMATION

n/a

[ansibot]

Files identified in the description:

• lib/ansible/modules/system/group.py

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibot]

cc @sfromm click here for bot help

[danielmotaleite]

i started to get this warning but found no references in the porting guide and no references how or what to fix.

most of my warnings are from the ec2.py, where the instance_id used the - (eg: i-033f62b586143dff7) and the regions (eg: eu-central-1c) , so we have no real fix for this ones

Finally, this broke some of my playbooks, where i used when: ansible_hostname in groups['varnish'] and the ansible_hostname is varnish-eu-central-1c-001 . In the past this worked fine, now i need to use inventory_hostname to get varnish_eu_central_1c_001 and get a match vs the groups['varnish']

So this needs at least and urgently a warning in the porting guide that inventory_hostname and groups[] may be returning different data

[ssbarnea]

What was the reasoning behind dropping the dash from group names? I really struggle to find good reason for that, especially as this will require lots of code refactoring.

[sivel]

@ssbarnea For one thing, we are making a push to only allow variable names, and other similar keys, that are valid python identifiers. To explain a little further about group names, it causes a problem for users trying to use "dot syntax" such as groups.foo-group, which doesn't do what the user expects. The number of issues and support requests caused by small problems like these has caused us to go down a path to safe guard names to ensure that problems like this do not occur.

For those wanting to keep what we consider invalid characters, can opt out of this functionality.

[caleb-s-cullen]

What must we do to opt out of this functionality? Our local Ansible deployment scripts are littered with hyphen-containing group names. We don't use them with dot notation, of course. But changing all of them would be a truly monumental task. I would prefer to opt out and at the same time encourage my team to avoid using hyphens in the future and where possible to convert hyphens to underscores, tho' that last part is not always as straightforward as it might seem.

So, does one simply set force_valid_group_names = false in ansible.cfg ? That seems right based on https://github.com/ansible/ansible/commit/d241794daa6d413e6447890e2a4f11e0d818cf0e#diff-fd24ad93fbc32f454761746c1ac908f2

[jamescassell]

What must we do to opt out of this functionality? Our local Ansible deployment scripts are littered with hyphen-containing group names. We don't use them with dot notation, of course. But changing all of them would be a truly monumental task. I would prefer to opt out and at the same time encourage my team to avoid using hyphens in the future and where possible to convert hyphens to underscores, tho' that last part is not always as straightforward as it might seem.

So, does one simply set force_valid_group_names = false in ansible.cfg ? That seems right based on d241794#diff-fd24ad93fbc32f454761746c1ac908f2

export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=never or export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore -- the latter is not in the docs yet: https://github.com/ansible/ansible/pull/57318

[al-x]

Thanks, James. Since people are coming to this issue to follow-up on the warning message, I'm including information I think may be useful:

To disable the ≥2.10 group name auto-transformation more portably/permanently until such time as you may be ready to clear out invalid groups from your inventory, add force_valid_group_names = never to the [defaults] INI-section of ansible.cfg.

To see all groups and invalid characters which trigger the warning (perhaps so you can target them for phase-out), you can do something like this ansible CLI no-op:

ansible-inventory -vvvv --host=localhost 2>&1 | grep replacing

These invalid characters are (as of 2019-06-04) defined as a constant, INVALID_VARIABLE_NAMES, in: https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119 as '^[\d\W]|[^\w]', that is: any leading non-alpha character OR any character other than alpha-numeric and underscore. (I hope I got that right)

If you find deprecation warnings annoying, you may also disable permanently them for any ansible- command or the ansible ad-hoc command by adding deprecation_warnings = False to the same [defaults] section of ansible.cfg, but I would recommend against that (since you may miss important news), and instead use inline shell environment variables like this: ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

The inventory parsing [WARNING]s won't go away, however. There's no specific config or env var to turn off all warnings (yet?), but if it really bugs you, you can just send all stderr to /dev/null (insert "best practice" caveats here):

2>/dev/null ansible-inventory --host=localhost

Hope this helps someone, somewhere.

[ssbarnea]

I only find deprecation warning messages annoying when they do not provide a migration path. Considering that the space is limited and that the remediation is likely to need update I would find very useful to provide links to tickets which can document solutions, workarounds,...

An approach like this could save extra work needed for improving incomplete warnings messages as we would not have to update the message, backport it to few versions back.

PS. Disabling deprecations warnings is something I would not recommend to anyone, maybe only if a project is already facing its ultimate fate ;)

[bpleines]

i started to get this warning but found no references in the porting guide and no references how or what to fix.

most of my warnings are from the ec2.py, where the instance_id used the - (eg: i-033f62b586143dff7) and the regions (eg: eu-central-1c) , so we have no real fix for this ones

Finally, this broke some of my playbooks, where i used when: ansible_hostname in groups['varnish'] and the ansible_hostname is varnish-eu-central-1c-001 . In the past this worked fine, now i need to use inventory_hostname to get varnish_eu_central_1c_001 and get a match vs the groups['varnish']

So this needs at least and urgently a warning in the porting guide that inventory_hostname and groups[] may be returning different data

I'd like to echo statement about the warning being generated by the EC2 dynamic inventory script. I noticed that there is an ec2.ini configuration setting to disable grouping hosts by instance_id (group_by_instance_id = False), but setting that didn't resolve the warning for me like I anticipated it would - I made sure I cleared the local inventory cache.

Any workarounds for EC2 dynamic inventory specifically?

[jamescassell]

These invalid characters are (as of 2019-06-04) defined as a constant, INVALID_VARIABLE_NAMES, in: https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119 as '^[\d\W]|[^\w]', that is: any leading non-alpha character OR any character other than alpha-numeric and underscore. (I hope I got that right)

Sounds accurate to me. You should submit a docs PR with that info.

If you find deprecation warnings annoying, you may also disable permanently them for any ansible- command or the ansible ad-hoc command by adding deprecation_warnings = False to the same [defaults] section of ansible.cfg, but I would recommend against that (since you may miss important news), and instead use inline shell environment variables like this: ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

The inventory parsing [WARNING]s won't go away, however. There's no specific config or env var to turn off all warnings (yet?), but if it really bugs you, you can just send all stderr to /dev/null (insert "best practice" caveats here):

The undocumented ignore option provides this functionality. Docs PR here: https://github.com/ansible/ansible/pull/57318

Starting in 2.8.2, this deprecation warning will be squashed if you explicitly set any of choices.

[maglub]

Where does the ansible dev team discuss this type of decisions? It is very hard for us users to understand the reasoning to this. If it is pure "python style" reasoning, rather than a practical reasoning, it might be worth reconsidering? If a dash in group names break things in future releases of ansible, it might rather be a problem with the implementation, more than the naming of a group?

To me, this sounds more like a cosmetic change, than something that has been thought through properly.

A group name is not a variable name, it is the content of such. A hyphen/dash is just a character, that also happens to be an extremely popular way of grouping information in a naming convention. Compared to the exclamation point or the star, it does not have a special meaning in a limit clause.

The cost to mitigate this issue is enorm, given that thousands of sites has to not only change the group names in the inventories, but also go through all their playbooks and home grown roles, and test them all again.

If there is any way at all for "peasants" to make their voice heard, I would love to chip in my opinion and try and understand how this idea came to be.

[jamescassell]

I've come to understand that the change was made to ansible because users made mistakes such as trying to use groups.group-name rather than groups['group-name']. AIUI, it is a change purely for the purpose of reducing support issues. (I'm personally opposed to the change.)

The old behavior will not go away; it will just become unavailable without explicitly choosing the old behavior.

[maglub]

Sad to hear.

My use case, is that I am embedding the command "ansible-inventory" in a Vagrant file, in a way where it is impolite to put things in ansible.cfg, and that it would help to be able to be able to override the behavior as a command line option (not environment variable).

Usually changes like this are due to good intentions, but might not always lead to the outcome one has in mind.

[MarkusTeufelberger]

My issue with this change is that group names now become somewhat "special" - dashes are allowed in host names, but not in group names which makes it a bit weird considering at the start of a playbook in the hosts: section I could write host and/or group names.

[equinox0815]

Is the explanation given by @sivel really the only reason behind this change? What about hosvars['foo-host'] then? I hope nobody is considering to make dashes invalid characters in inventory host names as well... Besides hostvars there are a ton of other examples where the "dot-notation" cannot be used so the need to know when to use which form will remain. I find it rather arbitrary to single out group names.

[KodinLanewave]

While the dot-notation argument is a somewhat valid excuse, I don't see this fixing your support issues without instead improving documentation. If your users are doing something stupid, your documentation isn't adequate. All the devs have succeeded in doing is alienating a lot of users. Group names I see as arbitrary string values. Restricting to alphanumeric and underscore honestly is somewhat of a pain, especially when hostname RFC's allow dashes, periods, etc... If underscores were the de-facto standard for naming conventions I don't think this would be an issue. Hyphens are used widely for descriptor strings. If you want to reduce your support volume try addressing the dot notation issue from another direction; build a validation script your support teams can provide that checks for best-practice issues and provides warnings or guidance as an example. Update your documentation about the dot-notation caveat to be big, bold, red, flashing, whatever... Such support cases end up being 1 minute calls if your documentation already covers the issue. Answer the phone, see the issue, provide the doc link, done.

[Jalle19]

Dashes in group names are both valid INI and valid YAML, I don't see why I as a user should have to rename all my groups just because the names can't be used as Python variable names?

[SpComb]

Also questioning the rationale behind this decision to deprecate - in group names. Not being able to use dashes in dynamic inventory keyed_groups was already annoying enough, but having to rename all of our groups in our inventory files and ansible-playbook -l ... commands just to avoid hypothetical syntax-related support issues is going to be painful.

FWIW we have a convention for naming role-groups like foo_server, and host-groups like foo-dev or foo-test. Almost 100% of our Ansible usage is commands like ansible-playbook -l foo-dev, so this change will take a lot of effort to fight muscle-memory.

[eengstrom]

Not sure if adding another me 2 here will encourage a reversal of this specific decision, but I tend to agree with the detractors of the requirement that group names be valid python identifiers.

[Cougar]

Please support hyphens together with letters, numbers and underscores in group names (but I don't have anything against dots either)!

We use hyphens heavily in group names. Both for grouping names like this:

[server-3x]
server-31.example.com
server-32.example.com
server-33.example.com

and to abuse inventory to keep host list in one place (instead of maintaining host names in different var files) like this:

[prometheus_node-exporter_cluster1:children]
server-3x
server-5x

We use such groups in templates like this:

{% set _hostgroup = [_service, _job, _cluster]|join('_') %}
{% set _hostlist = groups[_hostgroup]|d([])|sort %}
{% if _hostlist %}
{% for host in _hostlist %}
...

We don't use dots just to make visible differences between group and host names.

The word INVALID in TRANSFORM_INVALID_GROUP_CHARS doesn't give any confidence that it is possible to continue using them in long run.

If the intent is to avoid using these characters then better call them UNSAFE characters, show warning and let users decide if they see this warning or not. But never disallow or replace these characters!

Users should a) mute this warning (using keyword like ALLOW_UNSAFE_GROUP_CHARS), b) change their group names (when possible) or c) just live with that warning. Most will choose between first two options anyway.

[rrmestl-cx]

I also feel this is pointless, as a dash "-" is a standard delimiter character used in almost every type of computer related tool, and trying to conform to one "religion" seems constricting!!!

[SpComb]

The old behavior will not go away; it will just become unavailable without explicitly choosing the old behavior.

I wouldn't be as concerned about this deprecation if were actually possible to opt-in to dashes in group names. Then it might be understandable from a new-user perspective.

However, the deprecation warning implies that the TRANSFORM_INVALID_GROUP_CHARS=never option is going away in Ansible 2.10, and so we would need to start renaming all of our groups before Ansible 2.10 is released?

[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Also, using dynamic inventory plugin keyed_groups forces the transformation of group names, even if TRANSFORM_INVALID_GROUP_CHARS=never is set: https://github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/plugins/inventory/__init__.py#L45 https://github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/inventory/group.py#L39

Desired behavior

• Using TRANSFORM_INVALID_GROUP_CHARS=never needs to keep being supported in the future

  EDIT: reading the code, it sounds like the intention is to keep TRANSFORM_INVALID_GROUP_CHARS but change the default to always in 2.10 - in that case, the deprecation warning is not very well worded: https://github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/inventory/group.py#L50

• Using TRANSFORM_INVALID_GROUP_CHARS=never should silence the deprecation warning

  This seems to already be possible with the undocumented ignore option: https://github.com/ansible/ansible/pull/57318

• Using TRANSFORM_INVALID_GROUP_CHARS=never should also allow the use of dashes in dynamic inventory keyed_groups

  EDIT: this is clearly for backwards-compatibility for Ansible 2.7, which unconditionally transformed the generated group names. It would be great to have an explicit opt-out for this.

[Cougar]

Regarding variable names, I don't understand why should format of dictionary key be equalized with syntax of variable name? AFAIK no programming language has such limitation. In Python you can use pretty any string as dictionary key.

Isn't "groups" a dictionary type variable and both host and group names are just plain dictionary keys in Ansible. They are not properties nor variables themselves or are they?

I'd rather disallow groups.foo-group syntax than groups["foo-group"]. If g = "foo-group", then do you use groups.g or groups[g]?

[SpComb]

Using ansible.cfg [default] force_valid_group_names = ignore or export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore doesn't seem to work on Ansible 2.8.1. It still gives the deprecation warning.

$ ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore ANSIBLE_VAULT_PASSWORD_FILE=vault-password.secret ansible-playbook --diff -i xyz-dev.ini xyz-infra-install.yml -l xyz-dev --check
[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Is this because it's not yet listed in the valid choices? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

[jamescassell]

Using ansible.cfg [default] force_valid_group_names = ignore or export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore doesn't seem to work on Ansible 2.8.1. It still gives the deprecation warning.

$ ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore ANSIBLE_VAULT_PASSWORD_FILE=vault-password.secret ansible-playbook --diff -i xyz-dev.ini xyz-infra-install.yml -l xyz-dev --check
[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Is this because it's not yet listed in the valid choices? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

This is a bug that's fixed in the upcoming version 2.8.2. You'll be able to export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore and it will squash all warnings.

(The ignore option is still not documented: https://github.com/ansible/ansible/pull/57318 )

[markgoddard]

This is going to break everyone. Bad decision.

[maglub]

Would there be a way to reason with the maintainers about this?

Perhaps one of the maintainers could elaborate a bit here, if it is just a support issue or if they are using python constructs that really breaks?

[reubendevries]

I just want to add this quite annoying and the inablilty to really figure out the problem was also annoying, I litterally had to do ansible-playbook "insert yaml file here" > output.txt to figure out the problem.

[adamdonahue]

Concur with most of the posters here. Removal of dashes from group names seems like a poorly thought-through decision, or one that is implementation, not semantically, driven.

[jakubgs]

This change makes absolutely no sense to me. Ansible devs want to force thousands and thousands of users to change their group naming just because they want an additional syntax(not a missing one) for accessing groups? Is that a joke?

[krzysztof-magosa]

We use dashes and dots in big setup. Our pattern is product-name.environment.datacenter and it makes things very clear. I cannot imagine dropping - and . as that would make inventory totally unreadable.

[sebastianw]

We're using ansible inventory plugins that query the local CMDB for group names which contain (and will continue to contain) dashes. It would break a lot of stuff if this would be invalid in the future.

[mj84]

We use dashes and dots in big setup. Our pattern is product-name.environment.datacenter and it makes things very clear. I cannot imagine dropping - and . as that would make inventory totally unreadable.

We are using a similar approach with a hierarchical naming scheme (inspired by java, e.g. org.company.product-name.component). It would be an absolute horror having to revert to underscores.

[jbguerraz]

heh. we faced that issue as well. we're using dash in our groups names intensively. If one could explain what problem are due to the dash usage in a dict I would be happy to know

[markandrewj]

I am mainly reiterating what others have said, but I wanted to add some input. I think if this change is implemented, that the flag to allow dashes should be kept and maintained. Although I understand that Python expects underscores, dashes are commonly used for host names and host group names. In our environment we generate the inventory dynamically from hosts and host groups in our LDAP/Kerberos directory. I mention this because although it would be possible for us to change the host and group names, it is not preferable.

[rnsc]

What must we do to opt out of this functionality? Our local Ansible deployment scripts are littered with hyphen-containing group names. We don't use them with dot notation, of course. But changing all of them would be a truly monumental task. I would prefer to opt out and at the same time encourage my team to avoid using hyphens in the future and where possible to convert hyphens to underscores, tho' that last part is not always as straightforward as it might seem.

So, does one simply set force_valid_group_names = false in ansible.cfg ? That seems right based on d241794#diff-fd24ad93fbc32f454761746c1ac908f2

Test on Ansible 2.8.2, this INI setting doesn't work as expected I believe, this will only remove the DEPRECATION WARNING, while, what I want is for Ansible to use my groups with dashes without complaining.

Here are the results without:

[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. [WARNING]: Invalid characters were found in group names but not replaced, use -vvvv to see details

And with the setting set to "false" in ansible.cfg:

[WARNING]: Invalid characters were found in group names and automatically replaced, use -vvvv to see details

[rnsc]

Using ansible.cfg [default] force_valid_group_names = ignore or export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore doesn't seem to work on Ansible 2.8.1. It still gives the deprecation warning.

$ ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore ANSIBLE_VAULT_PASSWORD_FILE=vault-password.secret ansible-playbook --diff -i xyz-dev.ini xyz-infra-install.yml -l xyz-dev --check
[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Is this because it's not yet listed in the valid choices? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

This is a bug that's fixed in the upcoming version 2.8.2. You'll be able to export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore and it will squash all warnings.

(The ignore option is still not documented: ansible/ansible#57318 )

But is it just squashing warnings, or will that allow us to keep using dashes in groups? This is not very clear.

[duckie]

I agree with all the detractors here.

In addition to breaking playbooks, this contributes to what I call the convention mess in ansible. Now hostnames and groups names have a different convention, just because some isolated beginners stumble upon the hyphen issue in dot notation ? Guess what ? They will stumble on it still, and the feature will have succeeded in angrying people and not solving any problem. Bravo.

[wbertelsen]

Ansible group names should be capable of respecting the naming of the real world groups they represent.

If all other tooling calls a set of hosts my-backend-service why should ansible force operators to translate that to my_backend_service to satisfy python's naming rules.

[skyscooby]

It's is a really sad day today.. When a JR co-worker raised this deprecation to me I was like no way would the Ansible team be so out of touch with reality to make such a selfish choice. I absolutely love Ansible for what it can accomplish (from a user perspective that has ZERO to do with it being written in Python) The direction here to push PEP standards on end users makes me completely loose faith in the core Ansible development team's ability to make rational decisions. I hope IBM straightens it out.. OR Maybe there will be a new-shiny GO equivalent we can move to.

[mj84]

As this behavior is obviously very controversial, I am asking myself if this is a done deal and this is going to be implemented in any case?

I would very much appreciate a response from the people behind this decision and hope for some elaboration beyond "this is a python standard thing".

[maglub]

As this behavior is obviously very controversial, I am asking myself if this is a done deal and this is going to be implemented in any case?

I would very much appreciate a response from the people behind this decision and hope for some elaboration beyond "this is a python standard thing".

I agree with you. Just recently the "go" project backed out of an impopular proposal (see https://github.com/golang/go/issues/32437#issuecomment-512035919), so things like this can (and sometimes should) be revisited and eventually also backed out.

It is also an interesting topic and discussions, perhaps not only for this feature change. It is hard to figure out how the governance of Ansible as a product works. Perhaps something someone should bring with them to https://www.ansible.com/ansiblefest ?

As many of us are scratching our heads, not understanding how a string/variable content/group name in any way can pose any issues with python coding styles, it would be nice to get a reply here from the maintainers, arguing why this would pose an issue.

I can understand if they want to keep a coding style for variable names and structures, but the content of an array or variable?

Here is a quick discussion about dot notation of dicts. It is possible, but ugly. https://stackoverflow.com/questions/16279212/how-to-use-dot-notation-for-dict-in-python

[ramilehti]

The fact that there are support issues surrounding this is in my opinion a documentation issue not a functionality issue. If anything I would argue that group names should NOT be variables.

As is the fact that this change was implemented before any documentation was/is available.

[CMoH]

What is the impact of this change? Do I have to carefully edit all my ansible inventories to make sure I don't have dashes in group names?

[skyscooby]

@CMoH IMO the best workaround for now is to add force_valid_group_names = ignore to your configuration and run ansible 2.8.2 or later.

[Cougar]

@skyscooby, even this is a PITA. The thing that it is not possible to put this line as a default in /etc/ansible.cfg and use local ansible.cfg in playbook directories for other config. This means that all exitsing ansible.cfg files needs to be changed.

Or is there any way to set up global defaults (without adding another variable to the user environment)?

[skyscooby]

@Cougar agreed this choice from Ansible is a PITA..

Your problem however is not unique to this setting.. we experienced similar pain and now we discourage the use of per-project ansible.cfg files as most settings can be set with environment variables which override cfg file settings.. so if a projects for some obscure reason needs a specific setting we ask they use the ENV method which leaves the rest of the settings they don't need to change set to corporate standards. We build a base docker container with this standard configuration and individual projects simply add ENV entries into their own Dockerfile while basing their image of the base ansible container. All ansible is executed within the container so we are certain all pip modules, ansible versions and runtime tools are identical end to end.

EDIT: this also gives us the ability to stage in new versions of ansible and control issues like this before everyone in the company gets hit with them :)

[jamescassell]

I did some digging.

this functionality was originally added in PR https://github.com/ansible/ansible/pull/52748 allegedly to support the feature request https://github.com/ansible/ansible/issues/40581

one description of the goal: https://github.com/ansible/ansible/pull/52748#issuecomment-467976473

first version of THIS symptom (though different cause): https://github.com/ansible/ansible/issues/51844

[maglub]

Man, I have been reading ansible/ansible#52748 so many times now.

As I understand it, group names were previously sanitised in the plugins and the core, and someone (for whatever reason, as it is still not at all clear to me why) decided that group names should follow python variable naming conventions.

So ansible/ansible#52748 pushed the sanitation into the inventory instead, which breaks things for so many people. Especially people who use clever naming conventions, for example in AWS, Azure, etc, to map hosts to groups.

If we were to use the same standard/naming convention for host names, we would for sure lose momentum and lose users.

A group name is a name, not a variable. Using dashes in group names (just as in host names) makes sense. The translation (sanitation) should not need to be done on an inventory level (by us, the users), and in the best of all worlds actually never.

I really don't see the benefit of enforcing this. The discussion seems to cover also "." and ":", which some people like using in group names. Personally I don't use them, but I also don't see the harm in doing so.

As long as cloud providers re using dashes in their meta information, we should be able to use them for grouping. Actually, that should not even be the driver. If I feel like naming a group a-b-c-d-e, it should not really be an issue. It is a very useful delimiter.

This thread does not seem to attract any attention from devs or maintainers, though. I think we are speaking to deaf ears.

Devs/Maintainers: Please, pretty please allow dashes in group names!