I'm all for dashes and want to see them preserved as a valid character; I 
also want to explicitly point out that dots / periods (.) are also a valid 
character as they have been long in things like hostnames and packages to 
delineate strata as much as accessing things.  Outside of special cases 
like the k8s 
<https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/inventory/k8s.py#L218>
 and 
openshift 
<https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/inventory/openshift.py#L159>
 
inventory plugins where groups are created for things, which don't allow 
for periods in their own domains, there shouldn't be a reason it is denied.

On Sunday, August 4, 2019 at 9:02:51 AM UTC-4, Jörg Kastning wrote:
>
> Hello everybody,
>
> After updating to ansible 2.8.2 I faced the following deprecation warning 
> when running a playbook:
>
> [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
>>
>
> Searching for additional information on the web I found the two open 
> issues on GitHub: 
>
>
>    1. Provide means of flipping Ansible config 
>    TRANSFORM_INVALID_GROUP_CHARS #3513 
>    <https://github.com/ansible/awx/issues/3513>
>    2. TRANSFORM_INVALID_GROUP_CHARS doesn't document valid group patterns 
>    #56930 <https://github.com/ansible/ansible/issues/56930>
>
> In #56930 <https://github.com/ansible/ansible/issues/56930> a discussion 
> took place about the reasons for this change in default behaviour and 
> whether it would be a wise choice or not. The user bcoca 
> <https://github.com/bcoca> pointed out that GitHub is the wrong place for 
> these discussions to take place and summarized the reasons that have lead 
> to the current decision. He closed his comment 
> <https://github.com/ansible/ansible/issues/56930#issuecomment-516863432> 
> with the statement:
>
> I hope this addresses all the major issues, as always we are open for 
>> discussion, feel free to drop by ML or IRC, we just avoid using github 
>> since it is not a good place for such things.
>>
>
> So here we are. I hope this is a good place for this discussion to take 
> place. If there is any other mailing list that would be a better fit for 
> this discussion, please point me there.
>
> I understand that there is some confusion about variable names and group 
> names leading to a certain amount of support cases. Is that right? So the 
> default setting of TRANSFORM_INVALID_GROUP_CHARS is changed because some 
> people are trying to access a group name that they have mistaken for a 
> variable?
>
> IMHO changing the default setting is not a good idea, though. The hyphen 
> or the dash are common chars for group and host names in most environments. 
> To restrict them without a very good reason seems not to be wise.
>
> What I have not understand yet, do hyphens and dash causes confusion and 
> support cases or only the use of dots and colones etc.? Would it be 
> possible to only ban the chars that are causing the most of the trouble?
>
> In my environmen we are using dash/hyphen in almost every group name and 
> we won't change it. So I have to keep track and change the default every 
> time I setup a new environment. For me that's unfortunate. But if I have to 
> do it I would expect to have information on how to do so in documentation, 
> configuration files, porting guides, etc.
>
> Best regads,
> Joerg
>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ansible-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-devel/98a545b6-87ad-4762-9563-232e1867018f%40googlegroups.com.

Reply via email to