Arquivos identificados na descrição:

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

Se esses arquivos estiverem imprecisos, atualize a seção component name da descrição ou use o comando !component bot.

clique aqui para obter ajuda do bot

cc @sfromm
clique aqui para obter ajuda do bot

Comecei a receber este aviso, mas não encontrei referências no guia de portabilidade e nenhuma referência como ou o que corrigir.

a maioria dos meus avisos são do ec2.py, onde o instance_id usou o - (por exemplo: i-033f62b586143dff7 ) e as regiões (por exemplo: eu-central-1c ), então não temos correção real para estes

Finalmente, isso quebrou alguns dos meus manuais, onde usei when: ansible_hostname in groups['varnish'] e ansible_hostname é varnish-eu-central-1c-001 .
No passado, isso funcionava bem, agora eu preciso usar inventory_hostname para obter varnish_eu_central_1c_001 e obter uma correspondência contra groups['varnish']

Portanto, é necessário pelo menos e urgentemente um aviso no guia de portabilidade de que inventory_hostname e groups[] podem estar retornando dados diferentes

Qual foi o raciocínio por trás de retirar o travessão dos nomes dos grupos? Realmente me esforço para encontrar um bom motivo para isso, especialmente porque isso exigirá muita refatoração de código.

@ssbarnea Por um lado, estamos fazendo um push para permitir apenas nomes de variáveis ​​e outras chaves semelhantes, que são identificadores Python válidos. Para explicar um pouco mais sobre os nomes dos grupos, isso causa um problema para os usuários que tentam usar a "sintaxe de pontos", como groups.foo-group , que não faz o que o usuário espera. O número de questões e solicitações de suporte causadas por pequenos problemas como esses nos fez seguir um caminho para nomes de guarda seguros para garantir que problemas como esse não ocorram.

Para aqueles que desejam manter o que consideramos caracteres inválidos, podem cancelar essa funcionalidade.

O que devemos fazer para cancelar essa funcionalidade? Nossos scripts de implantação Ansible locais estão repletos de nomes de grupos contendo hífens. Não os usamos com notação de ponto, é claro. Mas mudar todos eles seria uma tarefa verdadeiramente monumental. Eu preferiria cancelar e, ao mesmo tempo, encorajar minha equipe a evitar o uso de hifens no futuro e, sempre que possível, converter hifens em sublinhados, embora essa última parte nem sempre seja tão direta quanto pode parecer.

Então, basta definir force_valid_group_names = false em ansible.cfg? Parece certo com base em https://github.com/ansible/ansible/commit/d241794daa6d413e6447890e2a4f11e0d818cf0e#diff -fd24ad93fbc32f454761746c1ac908f2

O que devemos fazer para cancelar essa funcionalidade? Nossos scripts de implantação Ansible locais estão repletos de nomes de grupos contendo hífens. Não os usamos com notação de ponto, é claro. Mas mudar todos eles seria uma tarefa verdadeiramente monumental. Eu preferiria cancelar e, ao mesmo tempo, encorajar minha equipe a evitar o uso de hifens no futuro e, sempre que possível, converter hifens em sublinhados, embora essa última parte nem sempre seja tão direta quanto pode parecer.

Então, basta definir force_valid_group_names = false em ansible.cfg? Parece certo com base em d241794 # diff-fd24ad93fbc32f454761746c1ac908f2

export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=never ou export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore - o último ainda não está nos documentos: https://github.com/ansible/ansible/pull/57318

Obrigado, James. Como as pessoas estão abordando esse problema para acompanhar a mensagem de aviso, estou incluindo informações que acho que podem ser úteis:

Para desativar a autotransformação de nome de grupo ≥2,10 de forma mais portável / permanente até o momento em que você possa estar pronto para limpar grupos inválidos de seu inventário, adicione force_valid_group_names = never à seção [defaults] INI de ansible.cfg .

Para ver todos os grupos e caracteres inválidos que acionam o aviso (talvez para que você possa direcioná-los para a eliminação progressiva), você pode fazer algo como este ansible CLI no-op:

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

Esses caracteres inválidos são (em 04/06/2019) definidos como uma constante, INVALID_VARIABLE_NAMES , em:
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
como '^[\d\W]|[^\w]' ,
isto é: any leading non-alpha character OR any character other than alpha-numeric and underscore .
(Espero ter entendido direito)

Se você achar os avisos de depreciação irritantes, você também pode desativá-los permanentemente para qualquer comando ansible- ou o comando ansible ad-hoc adicionando deprecation_warnings = False ao mesmo [defaults] section of ansible.cfg , mas eu não recomendaria isso (já que você pode perder notícias importantes) e, em vez disso, use variáveis ​​de ambiente de shell inline como estas:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

A análise de inventário [WARNING] s não vai embora, entretanto. Não há configuração específica ou env var para desligar todos os avisos (ainda?), Mas se realmente incomodar você, você pode simplesmente enviar todos os stderr para /dev/null (insira advertências de "prática recomendada" aqui):

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

Espero que isso ajude alguém, em algum lugar.

Eu só acho as mensagens de aviso de suspensão de uso irritantes quando não fornecem um caminho de migração. Considerando que o espaço é limitado e que a correção provavelmente precisará de atualização, seria muito útil fornecer links para tickets que podem documentar soluções, contornos, ...

Uma abordagem como essa poderia economizar trabalho extra necessário para melhorar as mensagens de advertência incompletas, pois não teríamos que atualizar a mensagem, retroceder para algumas versões de volta.

PS. Desativar os avisos de suspensão de uso é algo que eu não recomendaria a ninguém, talvez apenas se um projeto já estiver enfrentando seu destino final;)

Comecei a receber este aviso, mas não encontrei referências no guia de portabilidade e nenhuma referência como ou o que corrigir.

a maioria dos meus avisos são do ec2.py, onde o instance_id usou o - (por exemplo: i-033f62b586143dff7 ) e as regiões (por exemplo: eu-central-1c ), então não temos correção real para estes

Finalmente, isso quebrou alguns dos meus manuais, onde usei when: ansible_hostname in groups['varnish'] e ansible_hostname é varnish-eu-central-1c-001 .
No passado, isso funcionava bem, agora eu preciso usar inventory_hostname para obter varnish_eu_central_1c_001 e obter uma correspondência contra groups['varnish']

Portanto, é necessário pelo menos e urgentemente um aviso no guia de portabilidade de que inventory_hostname e groups[] podem estar retornando dados diferentes

Eu gostaria de repetir a declaração sobre o aviso que está sendo gerado pelo script de inventário dinâmico EC2 . Percebi que há uma definição de configuração ec2.ini para desabilitar o agrupamento de hosts por instance_id ( group_by_instance_id = False ), mas a configuração que não resolveu o aviso para mim como eu esperava - certifiquei-me de que limpou o cache de inventário local.

Alguma solução alternativa para o inventário dinâmico EC2 especificamente?

Esses caracteres inválidos são (em 04/06/2019) definidos como uma constante, INVALID_VARIABLE_NAMES , em:
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
como '^[\d\W]|[^\w]' ,
isto é: any leading non-alpha character OR any character other than alpha-numeric and underscore .
(Espero ter entendido direito)

Parece correto para mim. Você deve enviar um documento de relações públicas com essas informações.

Se você achar os avisos de depreciação irritantes, você também pode desativá-los permanentemente para qualquer comando ansible- ou o comando ansible ad-hoc adicionando deprecation_warnings = False ao mesmo [defaults] section of ansible.cfg , mas eu não recomendaria isso (já que você pode perder notícias importantes) e, em vez disso, use variáveis ​​de ambiente de shell inline como estas:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

A análise de inventário [WARNING] s não vai embora, entretanto. Não há configuração específica ou env var para desligar todos os avisos (ainda?), Mas se realmente incomodar você, você pode simplesmente enviar todos os stderr para /dev/null (insira advertências de "prática recomendada" aqui):

A opção ignore não documentada fornece esta funcionalidade. Docs PR aqui: https://github.com/ansible/ansible/pull/57318

A partir do 2.8.2, este aviso de reprovação será eliminado se você definir explicitamente qualquer uma das opções.

Onde a equipe de desenvolvimento do ansible discute esse tipo de decisão? É muito difícil para nós, usuários, entender o motivo disso. Se for puro raciocínio "estilo python", em vez de um raciocínio prático, pode valer a pena reconsiderar? Se um travessão nos nomes dos grupos quebrar as coisas em versões futuras do ansible, pode ser um problema com a implementação, mais do que com a nomenclatura de um grupo?

Para mim, isso soa mais como uma mudança cosmética do que algo que foi pensado corretamente.

Um nome de grupo não é um nome de variável, é o conteúdo de tal. Um hífen / travessão é apenas um caractere, que também é uma forma extremamente popular de agrupar informações em uma convenção de nomenclatura. Comparado com o ponto de exclamação ou a estrela, não tem um significado especial em uma cláusula limite.

O custo para mitigar esse problema é enorme, visto que milhares de sites precisam não apenas alterar os nomes dos grupos nos inventários, mas também examinar todos os seus manuais e funções caseiras e testá-los novamente.

Se houver alguma maneira de os "camponeses" fazerem sua voz ser ouvida, eu adoraria dividir minha opinião e tentar entender como essa ideia surgiu.

Eu entendi que a mudança foi feita no ansible porque os usuários cometeram erros, como tentar usar groups.group-name vez de groups['group-name'] . AIUI, é uma mudança puramente com o propósito de reduzir os problemas de suporte. (Eu pessoalmente me oponho à mudança.)

O antigo comportamento não vai embora; ele simplesmente se tornará indisponível sem escolher explicitamente o comportamento antigo.

Triste ouvir.

Meu caso de uso, é que estou incorporando o comando "ansible-inventory" em um arquivo Vagrant, de uma forma que é indelicado colocar coisas no ansible.cfg, e que ajudaria ser capaz de substituir o comportamento como uma opção de linha de comando (não variável de ambiente).

Normalmente, mudanças como essa são devidas a boas intenções, mas nem sempre podem levar ao resultado que se tem em mente.

Meu problema com essa mudança é que os nomes dos grupos agora se tornam um tanto "especiais" - traços são permitidos em nomes de hosts, mas não em nomes de grupos, o que torna isso um pouco estranho, considerando o início de um manual na seção hosts: Eu poderia escrever nomes de hosts e / ou grupos.

A explicação dada por @sivel é realmente a única razão por trás dessa mudança? Que tal hosvars['foo-host'] então? Espero que ninguém esteja considerando fazer travessões com caracteres inválidos em nomes de host de inventário também ...
Além de hostvars há uma tonelada de outros exemplos onde a "notação de ponto" não pode ser usada, então a necessidade de saber quando usar qual forma permanecerá. Acho bastante arbitrário destacar nomes de grupos.

Embora o argumento de notação de ponto seja uma desculpa válida, não vejo isso corrigindo seus problemas de suporte sem, em vez disso, melhorar a documentação. Se seus usuários estão fazendo algo estúpido, sua documentação não é adequada. Tudo o que os desenvolvedores conseguiram fazer é alienar muitos usuários. Os nomes dos grupos são valores de string arbitrários. Restringir o alfanumérico e o sublinhado honestamente é um tanto chato, especialmente quando as RFCs do nome do host permitem traços, pontos, etc ... Se os sublinhados fossem o padrão de fato para convenções de nomenclatura, não acho que isso seria um problema. Os hifens são amplamente usados ​​para sequências de descritores. Se você deseja reduzir o volume de suporte, tente abordar o problema da notação de pontos de outra direção; construir um script de validação que suas equipes de suporte podem fornecer para verificar os problemas de práticas recomendadas e fornecer avisos ou orientação como exemplo. Atualize sua documentação sobre a advertência de notação de ponto para ser grande, negrito, vermelho, piscando, o que for ... Esses casos de suporte acabam sendo chamadas de 1 minuto se sua documentação já cobre o problema. Atenda o telefone, veja o problema, forneça o link do doc, pronto.

Traços em nomes de grupos são INI e YAML válidos. Não vejo por que eu, como usuário, deveria renomear todos os meus grupos só porque os nomes não podem ser usados ​​como nomes de variáveis ​​Python.

Também questionando a lógica por trás dessa decisão de descontinuar - em nomes de grupos. Não poder usar travessões no inventário dinâmico keyed_groups já era irritante o suficiente, mas ter que renomear todos os nossos grupos em nossos arquivos de inventário e ansible-playbook -l ... comandos apenas para evitar hipotéticos problemas de suporte relacionados à sintaxe é vai ser doloroso.

FWIW, temos uma convenção para nomear grupos de funções como foo_server , e grupos de hosts como foo-dev ou foo-test . Quase 100% do nosso uso do Ansible são comandos como ansible-playbook -l foo-dev , então essa mudança exigirá muito esforço para combater a memória muscular.

Não tenho certeza se adicionar outro me 2 aqui irá encorajar uma reversão dessa decisão específica, mas tendo a concordar com os detratores da exigência de que nomes de grupo sejam identificadores Python válidos.

Por favor, aceite hífens junto com letras, números e sublinhados em nomes de grupos (mas também não tenho nada contra pontos)!

Usamos hifens muito em nomes de grupo. Ambos para nomes de agrupamento como este:

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

e _abuse_ inventário para manter a lista de hosts em um só lugar (em vez de manter nomes de host em arquivos var diferentes) como este:

[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 ([]) | classificar%}
{% if _hostlist%}
{% para host em _hostlist%}
...
`` `

Não usamos pontos apenas para fazer diferenças visíveis entre nomes de grupos e hosts.

A palavra INVALID em TRANSFORM_INVALID_GROUP_CHARS não dá nenhuma confiança de que é possível continuar a usá-los no longo prazo.

Se a intenção é evitar o uso desses caracteres, é melhor chamá-los de caracteres _UNSAFE_, mostrar aviso e permitir que os usuários decidam se verão esse aviso ou não. Mas nunca desautorize ou substitua esses personagens!

Os usuários devem a) silenciar este aviso (usando palavras-chave como ALLOW_UNSAFE_GROUP_CHARS), b) alterar seus nomes de grupo (quando possível) ou c) apenas viver com esse aviso. A maioria escolherá entre as duas primeiras opções de qualquer maneira.

Eu também acho que isso é inútil, já que um traço "-" é um caractere delimitador padrão usado em quase todo tipo de ferramenta relacionada ao computador, e tentar se adequar a uma "religião" parece constrangedor !!!

O antigo comportamento não vai embora; ele simplesmente se tornará indisponível sem escolher explicitamente o comportamento antigo.

Eu não ficaria tão preocupado com essa suspensão de uso se realmente fosse possível ativar travessões em nomes de grupos. Então, pode ser compreensível de uma perspectiva de novo usuário.

No entanto, o aviso de descontinuação implica que a opção TRANSFORM_INVALID_GROUP_CHARS=never será removida do Ansible 2.10 e, portanto, precisaríamos começar a renomear todos os nossos grupos antes que o Ansible 2.10 seja lançado.

[AVISO DE DEPRECAÇÃO]: As configurações de TRANSFORM_INVALID_GROUP_CHARS são definidas para permitir caracteres inválidos em nomes de grupos por padrão. Isso mudará, mas ainda poderá ser configurado pelo usuário em caso de suspensão. Este recurso será removido na versão 2.10. Os avisos de descontinuação podem ser desativados definindo deprecation_warnings = False em ansible.cfg.

Além disso, o uso do plugin de inventário dinâmico keyed_groups força a transformação dos nomes dos grupos, mesmo se TRANSFORM_INVALID_GROUP_CHARS=never estiver definido: https://github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/ plugins / inventário / __ init __. py # L45 https://github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/inventory/group.py#L39

Comportamento desejado

• O uso de TRANSFORM_INVALID_GROUP_CHARS=never deve continuar a ter suporte no futuro

  EDITAR: lendo o código, parece que a intenção é manter TRANSFORM_INVALID_GROUP_CHARS mas alterar o padrão para always em 2.10 - nesse caso, o aviso de suspensão de uso não é muito bem formulado: https: / /github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/inventory/group.py#L50

• Usar TRANSFORM_INVALID_GROUP_CHARS=never deve silenciar o aviso de suspensão de uso

  Isso parece já ser possível com a opção ignore não documentada: https://github.com/ansible/ansible/pull/57318

• Usar TRANSFORM_INVALID_GROUP_CHARS=never também deve permitir o uso de travessões no inventário dinâmico keyed_groups

  EDIT: isso é claramente para compatibilidade com versões anteriores para Ansible 2.7, que transformou incondicionalmente os nomes de grupo gerados. Seria ótimo ter um opt-out explícito para isso.

Com relação aos nomes das variáveis, não entendo por que o formato da chave do dicionário deve ser igualado com a sintaxe do nome da variável? AFAIK nenhuma linguagem de programação possui tal limitação. Em Python, você pode usar praticamente qualquer string como chave de dicionário.

Não é "grupos" uma variável do tipo de dicionário e os nomes de host e grupo são apenas chaves de dicionário simples em Ansible. Eles não são propriedades nem variáveis ​​ou são?

Prefiro proibir a sintaxe de groups.foo-group do que groups ["foo-group"]. Se g = "foo-group", então você usa groups.g ou groups [g]?

Usar ansible.cfg [default] force_valid_group_names = ignore ou export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore não parece funcionar no Ansible 2.8.1. Ele ainda fornece o aviso de suspensão de uso.

$ 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.

É porque ainda não está listado nos choices válidos? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Usar ansible.cfg [default] force_valid_group_names = ignore ou export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore não parece funcionar no Ansible 2.8.1. Ele ainda fornece o aviso de suspensão de uso.

$ 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.

É porque ainda não está listado nos choices válidos? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Este é um bug que foi corrigido na próxima versão 2.8.2. Você poderá export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore e isso eliminará todos os avisos.

(A opção de ignorar ainda não está documentada: https://github.com/ansible/ansible/pull/57318)

Isso vai quebrar todo mundo. Má decisão.

Haveria uma maneira de argumentar com os mantenedores sobre isso?

Talvez um dos mantenedores pudesse elaborar um pouco aqui, se é apenas um problema de suporte ou se eles estão usando construções python que realmente quebram?

Eu só quero adicionar isso muito chato e a incapacidade de realmente descobrir o problema também era chato, eu literalmente tive que fazer ansible-playbook "insert yaml file here" > output.txt para descobrir o problema.

Concorda com a maioria dos pôsteres aqui. A remoção de travessões dos nomes dos grupos parece uma decisão mal pensada ou que é orientada pela implementação, não semanticamente.

Essa mudança não faz absolutamente nenhum sentido para mim. Os desenvolvedores da Ansible desejam forçar milhares e milhares de usuários a alterar a nomenclatura de seus grupos apenas porque desejam uma sintaxe adicional (não faltando) para acessar grupos? Isso é uma piada?

Usamos travessões e pontos em grandes configurações.
Nosso padrão é product-name.environment.datacenter e torna as coisas muito claras.
Não consigo imaginar perder - e . pois isso tornaria o estoque totalmente ilegível.

Estamos usando plug-ins de inventário ansible que consultam o CMDB local em busca de nomes de grupos que contêm (e continuarão a conter) traços. Isso quebraria muitas coisas se fosse inválido no futuro.

Usamos travessões e pontos em grandes configurações.
Nosso padrão é product-name.environment.datacenter e torna as coisas muito claras.
Não consigo imaginar perder - e . pois isso tornaria o estoque totalmente ilegível.

Estamos usando uma abordagem semelhante com um esquema de nomenclatura hierárquico (inspirado em java, por exemplo, org.company.product-name.component).
Seria um horror absoluto ter que voltar para sublinhados.

heh. nós enfrentamos esse problema também. estamos usando o traço em nossos nomes de grupos intensivamente.
Se alguém pudesse explicar quais são os problemas devido ao uso do painel em um dicionário, eu ficaria feliz em saber

Estou reiterando principalmente o que outros disseram, mas gostaria de acrescentar algumas informações. Eu acho que se essa mudança for implementada, o sinalizador para permitir traços deve ser mantido e mantido. Embora eu entenda que o Python espera sublinhados, travessões são comumente usados ​​para nomes de host e nomes de grupo de host. Em nosso ambiente, geramos o inventário dinamicamente a partir de hosts e grupos de hosts em nosso diretório LDAP / Kerberos. Menciono isso porque, embora seja possível para nós alterar os nomes do host e do grupo, não é preferível.

O que devemos fazer para cancelar essa funcionalidade? Nossos scripts de implantação Ansible locais estão repletos de nomes de grupos contendo hífens. Não os usamos com notação de ponto, é claro. Mas mudar todos eles seria uma tarefa verdadeiramente monumental. Eu preferiria cancelar e, ao mesmo tempo, encorajar minha equipe a evitar o uso de hifens no futuro e, sempre que possível, converter hifens em sublinhados, embora essa última parte nem sempre seja tão direta quanto pode parecer.

Então, basta definir force_valid_group_names = false em ansible.cfg? Parece certo com base em d241794 # diff-fd24ad93fbc32f454761746c1ac908f2

Teste no Ansible 2.8.2, essa configuração INI não funciona conforme o esperado, acredito, isso apenas removerá o AVISO DE DEPRECATION, enquanto, o que eu quero é que o Ansible use meus grupos com travessões sem reclamar.

Aqui estão os resultados sem :

[AVISO DE DEPRECAÇÃO]: As configurações de TRANSFORM_INVALID_GROUP_CHARS são definidas para permitir caracteres inválidos em nomes de grupos por padrão. Isso mudará, mas ainda poderá ser configurado pelo usuário em caso de suspensão. Este recurso será removido na versão 2.10. Suspensão de uso
avisos podem ser desabilitados definindo deprecation_warnings = False em ansible.cfg.
[AVISO]: Caracteres inválidos foram encontrados em nomes de grupos, mas não foram substituídos, use -vvvv para ver os detalhes

E com a configuração definida como "false" em ansible.cfg:

[AVISO]: Caracteres inválidos foram encontrados em nomes de grupos e substituídos automaticamente, use -vvvv para ver os detalhes

Usar ansible.cfg [default] force_valid_group_names = ignore ou export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore não parece funcionar no Ansible 2.8.1. Ele ainda fornece o aviso de suspensão de uso.

$ 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.

É porque ainda não está listado nos choices válidos? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Este é um bug que foi corrigido na próxima versão 2.8.2. Você poderá export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore e isso eliminará todos os avisos.

(A opção de ignorar ainda não está documentada: # 57318)

Mas isso é apenas para eliminar os avisos ou isso nos permitirá continuar usando travessões em grupos?
Isso não está muito claro.

Eu concordo com todos os detratores aqui.

Além de quebrar manuais, isso contribui para o que chamo de bagunça de convenção no ansible. Agora, nomes de hosts e nomes de grupos têm uma convenção diferente, só porque alguns iniciantes isolados tropeçam no problema do hífen na notação de ponto? Adivinha ? Eles ainda vão tropeçar nele, e o recurso terá conseguido irritar as pessoas e não resolver nenhum problema. Bravo.

Os nomes de grupos compatíveis devem ser capazes de respeitar a nomenclatura dos grupos do mundo real que representam.

Se todas as outras ferramentas chamam um conjunto de hosts my-backend-service por que ansible forçaria os operadores a traduzir isso para my_backend_service para satisfazer as regras de nomenclatura do python.

É um dia muito triste hoje. Quando um colega de trabalho JR levantou essa depreciação para mim, eu pensei que de jeito nenhum a equipe da Ansible estaria tão desligada da realidade para fazer uma escolha tão egoísta. Eu absolutamente amo o Ansible pelo que ele pode realizar (da perspectiva do usuário que tem ZERO a ver com ser escrito em Python). A direção aqui para empurrar os padrões PEP para os usuários finais me faz perder completamente a fé na capacidade da equipe de desenvolvimento principal do Ansible de fazer decisões racionais. Espero que a IBM endireite isso ..
OU
Talvez haja um equivalente GO novo e brilhante para o qual possamos mudar.

Como este comportamento é obviamente muito controverso, pergunto-me se este é um negócio fechado e se vai ser implementado em qualquer caso?

Eu apreciaria muito uma resposta das pessoas por trás desta decisão e espero alguma elaboração além de "isso é uma coisa padrão do python".

Como este comportamento é obviamente muito controverso, pergunto-me se este é um negócio fechado e se vai ser implementado em qualquer caso?

Eu apreciaria muito uma resposta das pessoas por trás desta decisão e espero alguma elaboração além de "isso é uma coisa padrão do python".

Concordo com você. Recentemente, o projeto "go" foi retirado de uma proposta impopular (consulte https://github.com/golang/go/issues/32437#issuecomment-512035919), então coisas como esta podem (e às vezes devem) ser revisadas e eventualmente também desistiu.

É também um tópico e discussões interessantes, talvez não apenas por causa dessa mudança de recurso. É difícil descobrir como funciona a governança do Ansible como produto. Talvez algo _alguém_ deva trazer com eles para https://www.ansible.com/ansiblefest ?

Como muitos de nós estamos coçando a cabeça, não entendendo como uma string / conteúdo variável / nome de grupo de alguma forma pode representar qualquer problema com estilos de codificação Python, seria bom obter uma resposta aqui dos mantenedores, argumentando por que isso representaria um problema.

Posso entender se eles querem manter um estilo de codificação para nomes e estruturas de variáveis, mas o conteúdo de uma matriz ou variável?

Aqui está uma rápida discussão sobre a notação de pontos dos dictos. É possível, mas feio. https://stackoverflow.com/questions/16279212/how-to-use-dot-notation-for-dict-in-python

O fato de haver problemas de suporte em torno disso é, em minha opinião, um problema de documentação, não de funcionalidade. Se qualquer coisa, eu diria que os nomes dos grupos NÃO devem ser variáveis.

Assim como o fato de que essa mudança foi implementada antes que qualquer documentação estivesse / esteja disponível.

Qual é o impacto dessa mudança? Devo editar cuidadosamente todos os meus inventários ansible para garantir que não haja travessões nos nomes dos grupos?

@CMoH IMO a melhor solução por enquanto é adicionar force_valid_group_names = ignore à sua configuração e executar o ansible 2.8.2 ou posterior.

@skyscooby , até este é um PITA. A única coisa que não é possível colocar esta linha como padrão em /etc/ansible.cfg e usar ansible.cfg em diretórios de playbook para outras configurações. Isso significa que todos os arquivos ansible.cfg que saem precisam ser alterados.

Ou existe alguma maneira de definir padrões globais (sem adicionar outra variável ao ambiente do usuário)?

@Cougar concordou que essa escolha de Ansible é uma PITA.

Seu problema, no entanto, não é exclusivo para esta configuração .. experimentamos dor semelhante e agora desencorajamos o uso de arquivos ansible.cfg por projeto, pois a maioria das configurações podem ser definidas com variáveis ​​de ambiente que substituem as configurações do arquivo cfg .. então, se um projeto para algum motivo obscuro precisa de uma configuração específica, pedimos que usem o método ENV, que deixa o resto das configurações que não precisam ser alteradas para os padrões corporativos. Construímos um contêiner docker de base com esta configuração padrão e projetos individuais simplesmente adicionam entradas ENV em seu próprio Dockerfile enquanto baseiam sua imagem do contêiner ansible base. Todo o ansible é executado dentro do contêiner, então temos certeza de que todos os módulos pip, versões do ansible e ferramentas de tempo de execução são idênticos de ponta a ponta.

EDITAR: isso também nos dá a capacidade de criar novas versões do ansible e controlar problemas como este antes que todos na empresa sejam atingidos por eles :)

Eu fiz algumas escavações.

esta funcionalidade foi adicionada originalmente em PR https://github.com/ansible/ansible/pull/52748 supostamente para apoiar a solicitação de recurso https://github.com/ansible/ansible/issues/40581

uma descrição da meta: https://github.com/ansible/ansible/pull/52748#issuecomment -467976473

primeira versão DESTE sintoma (embora causa diferente): https://github.com/ansible/ansible/issues/51844

Cara, tenho lido # 52748 tantas vezes agora.

Pelo que entendi, os nomes dos grupos foram previamente limpos nos plug-ins e no núcleo, e alguém (por qualquer motivo, já que ainda não está claro para mim o porquê) decidiu que os nomes dos grupos deveriam seguir as convenções de nomenclatura de variáveis ​​do Python.

Portanto, o nº 52748 empurrou o saneamento para o estoque, o que quebra as coisas para tantas pessoas. Especialmente pessoas que usam convenções de nomenclatura inteligentes, por exemplo em AWS, Azure, etc, para mapear hosts para grupos.

Se fôssemos usar o mesmo padrão / convenção de nomenclatura para nomes de host, com certeza perderíamos ímpeto e usuários.

Um nome de grupo é um nome, não uma variável. O uso de travessões em nomes de grupo (assim como em nomes de host) faz sentido. A tradução (higienização) não deve precisar ser feita em nível de estoque (por nós, os usuários) e, no melhor dos mundos, nunca.

Eu realmente não vejo a vantagem de fazer cumprir isso. A discussão parece cobrir também "." e ":", que algumas pessoas gostam de usar em nomes de grupos. Pessoalmente, não os uso, mas também não vejo mal em fazê-lo.

Contanto que os provedores de nuvem estejam usando travessões em suas metainformações, devemos ser capazes de usá-los para agrupamento. Na verdade, esse nem mesmo deve ser o driver. Se eu quiser nomear um grupo abcde, isso não deve ser um problema. É um delimitador muito útil.

Este tópico não parece atrair nenhuma atenção de desenvolvedores ou mantenedores. Acho que estamos falando para ouvidos surdos.

Devs / Mantenedores: Por favor, por favor, permita travessões nos nomes dos grupos!

Para esclarecer alguns equívocos, parte deles foi devido aos meus erros e às mensagens iniciais não claras, as versões mais recentes têm correções para alguns dos problemas que as pessoas continuam trazendo à tona aqui, outras correções ainda estão surgindo:

Só para dizer uma vez, é claro que VOCÊ SEMPRE PODERÁ USAR TRAÇOS EM NOMES DE GRUPO também pontos e outros caracteres que agora são considerados 'inválidos', mas não por padrão. Este 'padrão' é o que está se tornando obsoleto, o padrão será 'seguro' no 2.11, mas você sempre terá a opção de 'aceitar' o comportamento antigo.

E para explicar como e por que chegamos aqui:

Primeiro, os nomes dos grupos foram SEMPRE limpos, eles apenas tinham diferentes regras inconsistentes, dependendo do tipo de inventário que você estava usando, os scripts estavam por toda parte, os formatos YAML e INI faziam cada um seu próprio trabalho. A principal mudança foi 'centralizar e normalizar o saneamento', isso foi decidido em 2.4, mas não foi totalmente implementado até 2.8. A intenção era fornecer uma norma ou linha de base que todos pudessem usar com segurança no Ansilbe, que dizia que reconhecemos que há muitas pessoas usando caracteres 'inseguros' ou 'inválidos' para variáveis, então tornamos isso configurável, não apenas globalmente, mas também por alguns dos plug-ins de inventário.

A implementação inicial teve alguns problemas e muita discussão (não, não decidimos isso se escondendo, temos reuniões públicas no irc para as quais todos são bem-vindos, https://github.com/ansible/community/blob/master /meetings/README.md) e muitos comentários foram incorporados (eles também são registrados para que você possa voltar para ver as discussões e o raciocínio, mas para evitar o 'log dumpster diving', explicarei a maioria dos problemas abaixo) . Depois de sair em 2.8, recebemos mais uma rodada de feedback e estamos corrigindo alguns bugs, como sempre obter uma depreciação, não apenas ao usar o padrão e principalmente com o texto da documentação e avisos.

• 'Por que nomes Python?'
  Principalmente porque Ansible usa Python e JInja (que também usa Python) e alguns usos de grupos (principalmente em nossos primeiros exemplos, mas também muitos de terceiros) podem criar erros em manuais, ou seja, stuff: '{{ groups.gropup-name-with-dash ... }}' ou pior, group.name.with.dots . Isso cria confusão para muitos usuários que desejam usar o recurso Jinja de 'notação de ponto para acesso variável' e é por isso que o padrão deve ser seguro para todos os usuários. A maioria das pessoas nesta postagem pode discordar disso, mas esse é um problema real para muitas pessoas e não deve ser uma 'armadilha' à espera de usuários novos ou antigos do Ansible. Aqueles que 'optam pela exclusão' são então responsáveis ​​por evitar o uso interrompido em outras partes do Ansible.

• 'E se eu gostasse que cada inventário tivesse um saneamento diferente?'
  Bem, você ainda pode desligar o saneamento 'central' e habilitar aquele para sua fonte de inventário específica, os novos plug-ins de inventário mais populares que substituem os scripts antigos tiveram opções adicionadas para emular o comportamento do script, o pior cenário, você ainda pode usar os scripts de inventário.

• 'Por que não nomes de host / são os próximos nomes de host?'
  Como para grupos, a limpeza de nomes de host sempre existiu, mas não mudou, os nomes de host têm requisitos diferentes, como ser DNS resolvível
  para conexões de rede ou um caminho válido para conexões chroot. Além disso, felizmente, há poucos ou nenhum exemplo de uso de nomes de host em notação de ponto. Isso não tem sido uma prática comum e se tornaria um problema se as pessoas começassem a usá-los repentinamente, mas, ao contrário dos nomes de grupo, isso é algo que evitamos até agora. Se continuar a ser um problema ... Também não vejo uma boa solução.

Observe que esse tíquete específico (descrição / informação insuficiente) é algo que já estou abordando, espero que conserte em breve. Quanto ao resto da discussão, os desenvolvedores não usam o Github como fórum, alguns tíquetes se transformam nisso, o tíquete anterior que está fechado e também tem um longo tópico foi ignorado até recentemente, principalmente porque os desenvolvedores filtram questões fechadas e espere discussões no IRC, a lista de correio ou novas questões.

Espero que isso aborde todas as questões importantes, como sempre estamos abertos para discussão, sinta-se à vontade para passar por ML ou IRC, apenas evitamos usar o github por não ser um bom lugar para tais coisas.

Muito obrigado pelo esclarecimento.

Agradeço por ter dispensado um tempo para explicar, embora fosse muito mais simples interromper o suporte à notação de ponto e descontinuar esse suporte em alguns lançamentos. Menos pessoas usam isso vs a quantidade de pessoas que têm caracteres inválidos em seus nomes de grupo. Se la vie

@skyscooby, o problema é que não é Ansible fazendo isso, é Jinja.

Só para dizer uma vez, é claro que VOCÊ SEMPRE PODERÁ USAR TRAÇOS EM NOMES DE GRUPO também pontos e outros caracteres que agora são considerados 'inválidos', mas não por padrão.

OK, é bom saber, obrigado pelo esclarecimento. No entanto, a experiência do usuário realmente precisa ser melhorada. Você tem a "maldição do conhecimento". Apenas tente se imaginar no lugar de um usuário que vê isto:

[AVISO DE DEPRECAÇÃO]: As configurações de TRANSFORM_INVALID_GROUP_CHARS são definidas para permitir caracteres inválidos em nomes de grupos por padrão. Isso vai mudar, mas ainda será
configurável pelo usuário em suspensão. Este recurso será removido na versão 2.10. Os avisos de descontinuação podem ser desativados definindo deprecation_warnings = False em ansible.cfg.
[AVISO]: Caracteres inválidos foram encontrados em nomes de grupos, mas não foram substituídos, use -vvvv para ver os detalhes

Esse é um longo, longo caminho de

[AVISO DE DEPRECAÇÃO] O nome do grupo 'meus-servidores' contém '-', que se tornará inválido por padrão a partir do Ansible 2.11. Defina force_valid_group_names em ansible.cfg ou a variável de ambiente ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS para "ignorar" para suprimir isso. Consulte https://docs.ansible.com/something para obter mais informações.

... que é o que eu, como usuário, realmente gostaria de ver. Isso teria me salvado mais de uma hora. Agora multiplique por isso pelo número de pessoas que tiveram ou terão esse problema.

Ter traços e pontos inválidos em nomes de grupo não é um padrão sensato. As pessoas sempre os terão em seus nomes de grupo. Exigir que eles definam outra variável em um arquivo de configuração para permitir um comportamento sensato é IMHO indefensável.

Obrigado @bcoca pelo seu comentário acima. É muito apreciado.

Embora não esteja satisfeito com a decisão, entendo que houve uma discussão e uma decisão foi tomada. Se a decisão ainda estiver aberta para debate, ela deve ser continuada na lista de mailling ou no irc, mas pode não abordar essa questão.

Para o tópico desta edição, gostaria de encontrar as seguintes informações na documentação oficial e nos guias de portabilidade, para estar ciente desta mudança.

• Quais são os nomes de grupo que são válidos por padrão?
• O que fazer para continuar usando nomes de grupo, incluindo travessões, hífens, pontos e dois pontos?

Porque usamos travessões em todos os nossos nomes de grupo e host e não vamos mudar isso. Portanto, tenho que ativar e alterar meu ansible.cfg toda vez que configuro uma nova instalação / ambiente. Isso é lamentável para mim, mas tenho que lidar com isso de alguma forma. O mínimo que eu esperaria é que isso seja devidamente documentado.

Para continuar a discussão sobre se essa mudança é sábia ou não, abri um tópico no grupo Ansible Development.

Atenciosamente,
Tronde

Quero agradecer a todos os contribuidores nesta questão. Com base no que li aqui, decidi escrever uma postagem no blog https://docs.sbarnea.com/ansible/naming-hosts-and-groups - Espero que resuma o que os usuários precisam fazer.

@ loop-evgeny Concordo que nós, como equipe principal, temos a "maldição do conhecimento" e isso nos inibe de criar documentos e erros que sejam úteis para todos. Também contamos totalmente com a comunidade para nos ajudar a moldar o ansible e mantê-lo simples para o maior número possível de usuários, então, quando alguém tiver recomendações sobre como melhorar nossos documentos e nossas mensagens de erro / aviso, sempre os incentivo a nos ajudar enviando um pullrequest. A mensagem que você apontou está no arquivo a seguir e agradeceríamos muito se você pudesse nos enviar um PR com a mudança sugerida ...

https://github.com/ansible/ansible/blob/4ef2545eb5d661566e06629015967c2d1b8924e3/lib/ansible/inventory/group.py#L54 -L55

@jctanner Normalmente, ficaria feliz em enviar um PR para melhorar um programa útil e gratuito que uso. No entanto, a atitude geral dos desenvolvedores do Ansible em relação à usabilidade, sua ânsia de fechar como "funcionando como pretendido" problemas que considero bugs evidentes (mesmo que sejam bugs de design) e o fato de que o Ansible atualmente tem 2025 (são dois mil !) Os RPs abertos me dão muito pouca confiança de que meu trabalho não será desperdiçado. Se você realmente quer "contar com a comunidade", como você diz, é necessária uma mudança cultural substancial IMHO.

Hmm .. Essa chance me atingiu também.

Infelizmente, usamos nomes de rede como nomes de grupo e isso não é facilmente alterável. Eu adoraria desativar o açúcar de sintaxe de ponto para nomes de grupo, pois não é nada que eu já usei (embora eu o use com outras variáveis).

Seria preferível usar ansible-playbook whatever.yaml -l some.network.to.use no futuro. Usar qualquer outro nome que não seja a rede como nome do grupo reduziria enormemente o caso de uso.

Oi,
Estou um pouco confuso no momento. Alguém poderia me dizer o que devo definir em ansible.cfg para permitir caracteres inválidos em nomes de grupo no futuro, por favor?

force_valid_group_names = ignore

Qual é a versão futura do ansible reavaliando para essas questões? Em algum momento, o ansible rejeitará todos os traços no nome do grupo sem uma solução alternativa usando force_valid_group_names ? (sem ouvir feedback de usuários que sofreram com a mudança e que nunca sofreram os problemas usando hífen em nomes de grupo)

Desculpe. Apenas li os comentários de @bcoca e

Oi,
Eu vejo o mesmo aviso, mas não entendo o que devo mudar e se devemos mudar.
É algo relacionado ao python?
Como resolver?

Se eu ignorar com force_valid_group_names = ignore, seria com isso necessário, e quando eu atualizar para Ansible> = 2.10?

Cumprimentos,
Cesar jorge

Se eu entendi isso corretamente. A única coisa que está obsoleta é a transformação automática de nomes de grupo. Isso significa que não há problema em definir force_valid_group_names = ignore após 2,10 e além.

Também não deve haver problema em continuar a usar travessões e o que quiser nos nomes dos grupos. O que o Ansible não fará no futuro é sanatizá-los para que você possa usar a notação pontilhada mesmo para nomes de grupo "inválidos". Por exemplo:

Seu inventário contém um grupo denominado foo-bar.xyz . Agora você deseja escrever um modelo que crie uma lista de hosts que pertencem a esse grupo:

{% for host in groups['foo-bar.xyz'] %}
{{ host }}
{% endfor %}

Lembre-se de que a seguinte versão do modelo não funcionaria:

{% for host in groups.foo-bar.xyz %}
{{ host }}
{% endfor %}

Isso ocorre porque - e . têm um significado especial neste caso. A notação pontilhada, entretanto, seria totalmente adequada se o seu grupo tivesse o nome foo_bar_xyz porque o modelo então se torna:

{% for host in groups.foo_bar_xyz %}
{{ host }}
{% endfor %}

O que é claro, está totalmente bem.

Na tentativa de tornar as coisas mais fáceis para os usuários, o Ansible aparentemente sempre fez alguma limpeza para nomes de grupos. Isso significa que era (e até 2.10 ainda é) possível usar foo_bar_xyz nos exemplos acima, embora o grupo na verdade seja denominado foo-bar.xyz . Pessoalmente, não acho que isso torne as coisas mais fáceis e parece que a equipe principal agora também concorda com isso.
Portanto, a próxima tentativa de resolver o problema é tornar impossível, em primeiro lugar, ter nomes de grupo "inválidos". No entanto, tanto quanto eu entendo, sempre será possível cancelar essa limitação definindo force_valid_group_names = ignore .

Resumindo, na verdade são duas mudanças diferentes que foram interligadas [1]. Daí o nome confuso e o texto da advertência.

Novamente, é apenas assim que eu entendo o problema. Por favor me corrija se eu estiver errado!

[1] para obter mais detalhes, consulte RFC1925, parágrafo 2, ponto (5)

Eu só queria deixar meus 2 centavos, já que estou firmemente ao lado de travessões> sublinhados. Apenas fazendo uma rápida pesquisa no Google sobre o assunto , quase universalmente os sublinhados são rotulados como inferiores aos traços para qualquer tipo de caminho e fins de rotulagem. Eles também são mais difíceis de trabalhar em muitos editores de texto e sistemas de arquivos.

Mesmo se esse não fosse o caso, o fato de eu ver travessões usados ​​para coisas como rótulos de servidor e grupos em estado selvagem com muito mais freqüência do que sublinhados significa que esta será mais uma coisa que terei que ter certeza de adicionar a todos os meus e os arquivos ansible.cfg meus clientes (costumo ter um por manual).

Não tenho nenhum problema com o Ansible tentando forçar um padrão mais rígido onde melhora a experiência, mas primeiro você veio pelos travessões nos nomes dos meus papéis (e às vezes permitiu exceções singulares para papéis mais antigos que foram adquiridos), então você veio pelos travessões em minhas coleções (elas não são permitidas de nenhuma maneira, forma ou forma), e agora você veio para travessões em meu inventário!

É uma guerra contra travessões lá fora ... e eu quero traçar um limite - neste caso, é o único lugar onde é realmente impossível para mim evitar que as pessoas usem travessões, já que muitos dos provedores de inventário dinâmico criam grupos com base em nomes e rótulos de servidores, e muitas (se não a maioria) organizações parecem rotular as coisas usando travessões (por exemplo, us-east-1a , não us_east_1a ).

Não é divertido ter um padrão que quase sempre deve ser sobrescrito para fazer o software funcionar, mas parece que a partir do Ansible 2.11, esse será o caso.

Se for tudo porque alguns usuários não familiarizados com Jinja2 e Python não percebem que something.with-some-dashes é inválido, eu diria que é melhor ensiná-los "se houver travessões, você deve usar a notação de colchetes para acesso de dicionário, por exemplo, something['with-some-dashes'] . Você pode até mesclar os dois, se necessário. Não é super puro e holístico, mas não somos todos desenvolvedores do Rust aqui ...

Muito bem colocado, Jeff. Concordo totalmente com você aqui - essa mudança será muito perturbadora e, em vez de apenas exigir uma migração única, mudará o fluxo de trabalho de um grande número de usuários. O Ansible não funcionará mais fora da caixa.

Os nomes de host não podem incluir um sublinhado, portanto, em um mundo são, o inventory_hostname não seria forçado a isso. Isso significa que nossos inventários parecerão bastante inconsistentes, com nomes de host que não podem conter sublinhados e grupos que não podem conter hifens.

Por favor, apenas não mude o padrão.

https://en.m.wikipedia.org/wiki/Hostname

Oi,
Eu concordo totalmente com Jeff aqui .

Mas, como @bcoca afirmou acima, a maioria dos desenvolvedores não vê essas discussões aqui regularmente e esse problema pode não ser o lugar certo para discutir a mudança porque se trata da documentação correta.

Para discussão, participe do tópico . Alterar a configuração padrão de TRANSFORM_INVALID_GROUP_CHARS é uma boa idéia? nos Grupos do Google.

Ótimos pontos, Jeff.

Não é divertido ter um padrão que quase sempre deve ser sobrescrito para fazer o software funcionar, mas parece que a partir do Ansible 2.11, esse será o caso.

Esta é a grande lição para mim de todas essas discussões. Eu entendo o problema que precisa ser resolvido, mas a solução parece ser o oposto do que é necessário. Isso torna as coisas mais fáceis para o suporte, mas difíceis para os usuários - essa é uma solução reversa.

Se for tudo porque alguns usuários não familiarizados com Jinja2 e Python não percebem algo. With-some-dashes é inválido, eu diria que é melhor ensiná-los "se houver travessões, você deve usar a notação de colchetes para acesso de dicionário, por exemplo, algo ['com-alguns-traços']. Você pode até mesclar os dois, se necessário.

Esta aqui é a melhor solução, não quebrar coisas que são usadas há anos.

Ótimo comentário de @geerlingguy - local!

Gostaria de acrescentar que, como usuário do Ansible, por que preciso saber o que é sintaxe válida do Python? Tendo usado o Ansible por um longo tempo, eu entendo que o Ansible (e seus módulos) é escrito em Python, mas por que devo me preocupar com isso? Expor esse fato ao usuário final é simplesmente um péssimo design.

Semelhante a permitir apenas a notação JavaScript / Ruby / .NET / qualquer coisa válida para coisas como nomes de usuário em um aplicativo da web. Por que o usuário final se importaria em qual idioma o aplicativo está escrito?

Além disso, introduzir mudanças significativas é um tópico difícil, tento evitar isso, se possível. Se eu tiver que fazer uma mudança, normalmente deixo o comportamento antigo e existente como padrão e deixo as pessoas optarem pelo novo comportamento. Por que isso não foi feito aqui? Por que tenho que alterar minha configuração ou, pior, todo o meu inventário? Por que não o contrário?

Se um sistema requer tokens estritamente compatíveis internamente, o sistema deve gerar internamente os tokens e criar uma tabela de pesquisa que associa os tokens internos aos dados do usuário. Dessa forma, o Ansible pode alterar suas regras de token conforme necessário e limitar o impacto sobre os usuários. Os usuários devem ser capazes de nomear seu inventário, funções, etc, como eles ou seus clientes considerarem adequado.

Parece-me que essa mudança pode ter o efeito oposto do pretendido (para diminuir as consultas de suporte):

Agora não há nenhum delimitador suportado (por padrão) tanto por nomes de host (que devem ser resolvidos pelo DNS, ou seja, não contêm sublinhados) e nomes de grupos (que não devem conter travessões).

Definitivamente, deve ser livre para nomear qualquer host

El mié., 14 atrás. 16:16 de 2019, Christian Pointner [email protected]
escribió:

Se eu entendo isso
https://github.com/ansible/ansible/issues/56930#issuecomment-516863432
corretamente. A única coisa que está obsoleta é o sistema automático
transformação de nomes de grupos. Isso significa que não deve haver problema em definir force_valid_group_names
= ignorar após 2.10 e além.

Também deve ser totalmente normal continuar a usar travessões e tudo o que você
não quer em nomes de grupo. O que Ansible não fará no futuro é higienizar
para que você possa usar a notação pontilhada mesmo para nomes de grupo "inválidos". Para
exemplo:

Seu inventário contém um grupo denominado foo-bar.xyz. Agora você quer escrever
um modelo que cria uma lista de hosts que pertencem a esse grupo:

{% para host em grupos ['foo-bar.xyz']%}
{{ hospedeiro }}
{% endfor%}

Lembre-se de que esta versão do modelo não funcionaria:

{% para host em grupos.foo-bar.xyz%}
{{ hospedeiro }}
{% endfor%}

Isso ocorre porque o - e o. têm um significado especial neste caso. o
notação pontilhada, no entanto, seria totalmente adequada se o seu grupo tivesse o
nomeie foo_bar_xyz porque o modelo então se torna:

{% para host em grupos.foo_bar_xyz%}
{{ hospedeiro }}
{% endfor%}

O que é claro, está totalmente bem.

Na tentativa de tornar as coisas mais fáceis para os usuários, o Ansible aparentemente sempre
fez algum saneamento para nomes de grupos. Isso significa que era (e até 2.10
ainda é) possível usar foo_bar_xyz nos exemplos acima, embora
o grupo na verdade é denominado foo-bar.xyz. Pessoalmente eu não acho isso
torna as coisas mais fáceis e parece que a equipe principal agora também concorda
com isso.
Portanto, a próxima tentativa de resolver o problema é tornar impossível ter
nomes de grupos "inválidos" em primeiro lugar. No entanto, tanto quanto eu entendo
sempre será possível cancelar essa limitação configurando force_valid_group_names
= ignorar.

Resumindo, na verdade são duas mudanças diferentes que foram
entrelaçados [1] uns com os outros. De onde vem o nome confuso e a redação de
O aviso.

Novamente, é apenas assim que eu entendo o problema. Por favor me corrija se eu sou
errado!

[1] para mais detalhes, consulte RFC1925
http://www.faqs.org/rfcs/rfc1925.html Parágrafo 2, Ponto (5)

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ansible/ansible/issues/56930?email_source=notifications&email_token=AA5N2CJCIELW7JWHC6OJ35DQEQHSPA5CNFSM4HPRGLKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4I5U3Y#issuecomment-521263727 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AA5N2CIVT5PLD2QCAGGBK6LQEQHSPANCNFSM4HPRGLKA
.

Esta é realmente uma decisão errada na minha opinião honesta. E pelo motivo errado. Reduzindo o número de solicitações de suporte, realmente?

O Ansible, como ferramenta, não deve impor detalhes específicos do idioma ao usuário final. Já estou tão chateado com o Terraform me impondo todo aquele Golang goela abaixo, agora o mesmo está acontecendo aqui com o Ansible e o estilo "pythônico". Não me interpretem mal, eu trabalho muito bem com Go e Python, mas quando se trata de infraestrutura como código, por que devo me importar? E o que aconteceu com a promessa de ter YAML ditando a forma da base de código a ser gerenciada? "Infraestrutura como dados, que você pode ler e executar", ouvi isso tantas vezes ... Até onde eu sei, o YAML não liga para travessões e sublinhados.

Aliás, existem várias coisas por aí que não suportam sublinhados. Nomes de host, regiões da AWS e IDs para literalmente tudo, apenas para mencionar alguns realmente importantes. Boa sorte em manter todas as exceções onde a transformação não deveria acontecer ...

Para as pessoas que vêm aqui apenas em busca de uma solução rápida sobre como fazer isso desaparecer, basta adicionar a linha force_valid_group_names = ignore ao seu ansible.cfg e ser feliz.

Meu entendimento é que você não pode usar a notação de ponto para variáveis ​​com espaços de qualquer maneira, e embora eu nunca crie variáveis ​​com espaços, infelizmente há muitos fornecedores que retornam chaves de dicionário com espaços por meio de respostas da API json. A opção sensata para mim parece mudar para a notação de colchetes. Esperançosamente, configurar force_valid_group_names para ignorar não causa efeitos nocivos no futuro, quem sabe o que mais está planejado no futuro com esta mudança.

Esta é uma decisão muito terrível, especialmente quando se trata de trabalhar com estoques dinâmicos como o Openstack (e AWS).
Nomes de instâncias e chaves de metadados contendo "caracteres proibidos" são freqüentemente retornados como itens de inventário e / ou variáveis ​​de grupo da nuvem subjacente. Isso vai tornar a vida de muitos administradores do Openstack (e AWS) que tentam gerenciar suas frotas usando metatags e / ou IDs de instância como:
instance-8ca09c33-f255-440f-9544-b0ab318c79d9
meta-os_ubuntu

Os desenvolvedores de Ansible devem levar a opinião @geerlingguy a sério. Ele é um dos maiores contribuidores do Ansible Galaxy e seus papéis são consumidos por toneladas de pessoas. Acho que essa mudança é muito ruim para pessoas que têm milhares de hosts nomeados como: $env-$role-[0..99] . Devemos renomear tudo para apaziguar nossos senhores Ansible?

@ssbarnea Por um lado, estamos fazendo um push para permitir apenas nomes de variáveis ​​e outras chaves semelhantes, que são identificadores Python válidos. Para explicar um pouco mais sobre os nomes dos grupos, isso causa um problema para os usuários que tentam usar a "sintaxe de pontos", como groups.foo-group , que não faz o que o usuário espera. O número de questões e solicitações de suporte causadas por pequenos problemas como esses nos fez seguir um caminho para nomes de guarda seguros para garantir que problemas como esse não ocorram.

Para aqueles que desejam manter o que consideramos caracteres inválidos, podem cancelar essa funcionalidade.

Por quanto tempo os usuários terão permissão para cancelar esse comportamento? Haverá uma opção de configuração permanente para desabilitar este comportamento em todas as versões do ansible daqui para frente, ou ela só será suportada até 2.11? Ficaria feliz com a opção de ser ativado por padrão, contanto que sempre tenha a opção de desativá-lo.

Se isso se tornar uma restrição rígida no 2.11+, você provavelmente perderá clientes que estão limitados pelas restrições de sua organização (nem todos os usuários ansible têm o poder de ditar as convenções de nomenclatura usadas por sua empresa). Parece que essa mudança também introduziria um desafio significativo para aqueles que usam o ansible para gerenciar a infraestrutura em nuvem, onde travessões tendem a ser muito usados.

Apenas para lembrar aqueles que não leram todo o tópico aqui. Também há um tópico na lista de mailling devel: https://groups.google.com/forum/#!topic/ansible -devel / bjAcM9ferIw

IMHO esta mudança foi uma escolha muito ruim. Mudanças de sintaxe de quebra de código em versões de lançamento menores nos impedem de estender o uso de Ansible em nosso ambiente. Porque não poderei atualizar o Ansible quando ele quebrar os manuais dos meus usuários.

Mas, como @bcoca afirmou acima, a maioria dos desenvolvedores não vê essas discussões aqui regularmente e esse problema pode não ser o lugar certo para discutir a mudança porque se trata da documentação correta.

@Tronde : alguém poderia argumentar que contribuidores E clientes são consultados antes que as histórias sejam escritas para entender o impacto e obter feedback bem antes de alguém codificar uma solução. Como vários aqui mencionaram, esta é uma falha de gerenciamento de produto que vimos mais de uma vez.

Como um exemplo da situação que @andyfeller descreve sobre essa mudança:

Temos um problema com isso em nosso site.

Usamos o Red Hat Identity Manager como um inventário externo, não o controlamos, ele contém muitos grupos de hosts com travessões em vez de sublinhados. Isso não será alterado (por causa de todas as outras coisas que existem usando esses nomes).

Então, precisamos:

• Para configurar o Ansible para manter o comportamento atual
• Silencie o aviso de suspensão de uso
• Faça isso para a linha de comando Ansible e Ansible Tower

FYI PR https://github.com/ansible/ansible/pull/66650 (por favor, sem forcados) está programado para 2.10 (no momento atual), o que significa que qualquer pessoa que vir este aviso iria (assim que atualizar para 2.10, novamente assumindo que PR é mesclado) comece a ter falhas de manual em vez disso (até que eles definam force_valid_group_names = ignore em um ansible.cfg ).

Apenas postando para visibilidade. Ainda estou firmemente por trás da minha afirmação anterior de que este é um padrão hostil ao usuário, já que ainda existem muitos scripts de inventário dinâmico (alguma parte do próprio Ansible ou agora movidos para coleções 'oficiais') que geram nomes de grupo com travessões ou outros caracteres DNS válidos.

Praticamente qualquer pessoa que use Ansible com AWS terá que substituir o padrão.

@geerlingguy Esse é o PR # certo? Parece que isso aponta para esse problema.

Para sua informação, isso foi discutido em uma Reunião Principal aqui , começando em 19:06:55

@ apple4ever ops , atualizei o link, é https://github.com/ansible/ansible/pull/66650

Então eu vi acima muitos comentários de coisas que já foram respondidas / desmascaradas / etc, então só vou linkar aqui meu post anterior.

https://github.com/ansible/ansible/issues/56930#issuecomment -516863432

Não adicione novas postagens que não adicionem NOVOS itens para discussão, pois elas ocultam as anteriores que já foram respondidas.

A propósito, onde seria um bom lugar para criar um link na documentação do Python sobre como são os nomes de variáveis ​​válidos? Existe https://docs.python.org/3/reference/lexical_analysis.html#grammar -token-identifier, mas isso não é muito amigável ou legível para pessoas sem experiência em ciência da computação.

O motivo da pergunta é que não tenho certeza se a reclamação inicial real foi realmente tratada. Há apenas um aviso de que há algo errado, mas é preciso pesquisar muito para descobrir o que exatamente e como alguém - se quiser ou puder - pode realmente escolher um nome de grupo válido. Eu esperaria pelo menos um claro "O nome do grupo foo-bar contém caracteres inválidos ( - ). Nomes de grupos válidos devem ser identificadores Python válidos (consulte https://docs.python.org/??? para obter mais informações)" mensagem, não apenas "há caracteres ruins, verifique novamente com -vvvv para realmente descobrir quais!". Idealmente, isso também mencionaria que isso pode ser desativado, mas poderia levar a outros problemas inesperados (como tornar realmente difícil para Ansible distinguir os grupos foo-bar , foo.bar e foo_bar )

Atualmente, é mais uma mensagem do tipo "Você fez algo errado, corrija" sem uma forma clara de como proceder, o que também pode ter contribuído para a forte resposta aqui.

@geerlingguy escreveu no comentário 56930 :

(até definir force_valid_group_names = false em um ansible.cfg)

A documentação não menciona 'false' como um valor válido para esta chave. Eu defini o valor como 'ignorar', o que deve funcionar. Mas 'false' é uma palavra-chave inválida ou está correta e a documentação não está completa aqui?

@bcoca em um comentário anterior:

Só para dizer uma vez, é claro que VOCÊ SEMPRE PODERÁ USAR TRAÇOS EM NOMES DE GRUPO também pontos e outros caracteres que agora são considerados 'inválidos', mas não por padrão. Este 'padrão' é o que está se tornando obsoleto, o padrão será 'seguro' no 2.11, mas você sempre terá a opção de 'aceitar' o comportamento antigo.

Você afirmou repetidamente que o comportamento atual pode ser preservado, mas quais são as configurações exatas de ansible.cfg necessárias para fazer isso _agora_ e eliminar o aviso de depreciação.

Eu tentei como @geerlingguy escreveu no comentário 56930:

(até definir force_valid_group_names = false em um ansible.cfg)

O que faz com que meus manuais falhem quando não consegue encontrar hosts ou grupos com hifens (eles estão vindo de um plugin de inventário que escrevemos BTW, estes têm que fazer a transformação também, ou isso é feito quando o Ansible ingere o inventário de o plugin?)

Eu tentei como @geerlingguy escreveu no comentário 56930:

(até definir force_valid_group_names = false em um ansible.cfg)

O que faz com que meus manuais falhem quando não consegue encontrar hosts ou grupos com hifens (eles estão vindo de um plugin de inventário que escrevemos BTW, estes têm que fazer a transformação também, ou isso é feito quando o Ansible ingere o inventário de o plugin?)

Isso foi mencionado em vários comentários e está na documentação . Você deve usar nunca ou ignorar .

Então, não devemos mais usar o script de inventário dinâmico EC2, já que ele agrupa tudo por 'us-east-1', 'us-east-2', etc? Ou existe um plano para atualizá-lo? Acabei de acessar a documentação do Ansible para o script de inventário dinâmico do EC2 e o link para baixá-lo no Github não funciona mais, o que é interessante.

Acabei de acessar a documentação do Ansible para o script de inventário dinâmico do EC2 e o link para baixá-lo no Github não funciona mais, o que é interessante.

Veja https://github.com/ansible/ansible/issues/68419

para aqueles de vocês que não se preocupam em ler o log do IRC, aqui está a decisão, ou seja, nenhuma decisão:

19:15:40 <sivel> I've got to say, that brining this topic up all the time isn't a good use of time
19:15:52 <cyberpear> bcoca nominated it
19:16:07 <felixfontein> I think the aim was to solve this once and for all (like, again :) )
19:16:29 <cyberpear> since bcoca is not here, move on to next topic?
19:16:34 <sivel> honestly, I don't think this is going to be the right forum to make a decision on this
19:16:45 <jillr> +2 moving on
19:16:47 <cyberpear> sivel: what's the correct forum?
19:16:55 <felixfontein> sivel: what is the right forum for making that decision?
19:17:02 <cyberpear> "declaration from Red Hat On High"?
19:17:15 <sivel> I'm going to abstain on that, but this project is not a democracy
19:17:16 <cyberpear> -1 to "declaration from Red Hat On High"
19:17:24 <sivel> too many cooks in the kitchen distract
19:17:45 <sivel> We know the arguments at this point
19:17:59 <sivel> anywho, next topic

sim, alguém escreveu "sinta-se à vontade para passar por ML ou IRC". não, "este projeto não é uma democracia".

sim, alguém escreveu "sinta-se à vontade para passar por ML ou IRC". não, "este projeto não é uma democracia".

Para ser honesto, isso está errado com o código-fonte aberto - se levar a um caminho pouco popular - as pessoas podem fazer um fork dele, pode ser um fork?

Eu posso ver que aceitar PR no ansible é terrivelmente lento. Patches parecem obviamente necessários e uma mudança simples, mas nunca entra. Felizmente, o ansible em si é flexível para permitir que as pessoas usem plug-ins customizados, embora pareça obsoleto me tornará menos nas contribuições - ou ainda mais incômodo para fazê-lo.

Me sentindo um pouco triste, sério ...

@ sunshine69 Eu sinto sua dor. Mas essa é uma discussão que deveria ocorrer no IRC ou no Google Group for Ansible Development.

Este problema não é o lugar certo para isso. Porque para poucas pessoas lêem aqui.

@ sunshine69 Eu sinto sua dor. Mas essa é uma discussão que deveria ocorrer no IRC ou no Google Group for Ansible Development.

Este problema não é o lugar certo para isso. Porque para poucas pessoas lêem aqui.

Embora a discussão possa ser mais produtiva nesses outros canais, a transparência é apreciada para as pessoas que acompanham esta questão especificamente. Afinal, o IRC não é a preferência de todos.

Para sua informação: Remover descontinuação de TRANSFORM_INVALID_GROUP_CHARS foi mesclado ontem. Existem PRs backport para 2.9 (https://github.com/ansible/ansible/pull/69487) e 2.8 (https://github.com/ansible/ansible/pull/69488) para remover os avisos de descontinuação.

Arquivos identificados na descrição:

• lib/ansible/modules/group.py

Se esses arquivos estiverem incorretos, atualize a seção component name da descrição ou use o comando !component bot.

clique aqui para obter ajuda do bot

Quando eu configurei force_valid_group_names = ignore o AVISO foi embora, mas o AVISO DE DEPRECATION não foi embora.

Finalmente encontrei na documentação: force_valid_group_names = silently que fará a substituição e não obstruirá a saída - se é isso que você está procurando fazer.

No entanto, todo esse problema poderia ter sido evitado em primeiro lugar se mudanças inúteis como essa não fossem feitas em primeiro lugar.

@ emmm-dee - Para esse problema específico, abri https://github.com/ansible/ansible/issues/70908 - observe que esse problema ainda persiste, pois ainda não há documentação oficial para quais _são_ caracteres de grupo 'válidos' .

obrigado a @geerlingguy por suas ações! Você é quem está tornando o ansible melhor.

Estou trabalhando em nosso aplicativo de salto (iniciar / parar), mas não estou conectado ao host do aplicativo.

Tentei o comando ping, que você enviou e funciona ...

[ webadmin @ vlodjumpts00 ~] $ ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56 (84) bytes de dados.

64 bytes de 8.8.8.8: icmp_seq = 1 ttl = 112 tempo = 10,6 ms

[ webadmin @ vlodjumpts00 ~] $ mirrorlist.centos.org

-bash: mirrorlist.centos.org: comando não encontrado

Eu quero usar isso para nossa organização .. se eu executei o comando "ansible all -m ping". enfrentando o erro, abaixo estão os detalhes:

[ aa63457 @ vlodjumpts00 bin] $ ansible all -m ping

mudar, mas ainda ser configurável pelo usuário na descontinuação. Este recurso será removido na versão 2.10. Os avisos de suspensão de uso podem ser

desativado definindo deprecation_warnings = False em ansible.cfg.

RTE3EPAdmin | INACESSÍVEL! => {

"changed": false,

"msg": "Failed to connect to the host via ssh: ###############################################################################\n# CenturyLink computers and the CenturyLink computer network are CenturyLink  #\n# property. Only authorized persons may use them and only for legal and proper#\n# purposes as determined solely by CenturyLink. You consent to the monitoring #\n# of their use. You must use CenturyLink computers and the network in         #\n# accordance with the CenturyLink Code of Conduct, subject to discipline for  #\n# misuse. Customer use is governed by the CenturyLink Acceptable Use Policy.  #\n###############################################################################\nUse CTL credentials (login/password) on this server.\nAUTH-NOTICE:\nAUTH-NOTICE: Use your cuid as your username\nAUTH-NOTICE:\nPermission denied (publickey,password).",

"unreachable": true

}

localhost | SUCESSO => {

"ansible_facts": {

    "discovered_interpreter_python": "/usr/bin/python"

},

"changed": false,

"ping": "pong"

}

Por favor me ajude ... o que eu preciso fazer isso. Na verdade, não temos UN / PWD para arquivo de hosts para conectar a máquina host.

localhost ansible_connection = local

[RTE3VFO]

RTE3VFOAdmin ansible_host = vlddwblasts001.test.intranet

RTE3VFOManaged ansible_host = vlddwblasts002.test.intranet

[RTE3EP]

RTE3EPAdmin ansible_host = vlddwblasts002.test.intranet

RTE3EPManaged ansible_host = vlddwblasts003.test.intranet

[RTE3RES]

RTE3RESAdmin ansible_host = vlddwblasts003.test.intranet

RTE3RESAManaged ansible_host = vlddwblasts004.test.intranet

[RTE3ORCH]

RTE3ORCHAdmin ansible_host = vlddwblasts004.test.intranet

RTE3ORCHManaged ansible_host = vlddwblasts005.test.intranet

[RTE3EASE]

RTE3EASEAdmin ansible_host = vlddwblasts005.test.intranet

RTE3EASEManaged ansible_host = vlddwblasts006.test.intranet

[RTE3RTS]

RTE3RTSAdmin ansibke_host = vlddwblasts006.test.intranet

[EASE-ASR-Test2: crianças]

RTE3VFO

RTE3EP

RTE3RES

RTE3ORCH

RTE3EASE

RTE3RTS

e a estrutura do diretório é:

[ webadmin @ vlodjumpts00 ansible] $ pwd

/ etc / ansible

[ webadmin @ vlodjumpts00 ansible] $ ll

total de 84

-rw ------- 1 webadmin webadmin 607 12 de julho de 2017 1

-rw-r - r-- 1 webadmin webadmin 17910 Set 19 09:55 ansible.cfg

-rw-r - r-- 1 root 19985 8 de dezembro de 2019 ansible.cfg.rpmnew

-rw ------- 1 webadmin webadmin 213, 3 de julho de 2017 easeasr-rte2-facilidade.yml

-rwxr-xr-x 1 webadmin webadmin 1034 19 de setembro 09:16 facilidade-hosts

-rwxr-xr-x 1 webadmin webadmin 1647 19 de setembro 10:50 hosts

-rw ------- 1 webadmin webadmin 2679 3 de julho de 2017 hosts.bkp

-rw ------- 1 webadmin webadmin 273 6 de julho de 2017 lineinsfile_tst.yml

drwx ------ 4 webadmin webadmin 4096 manuais de 2 de novembro de 2017

funções drwxr-xr-x 3 root 19 de dezembro de 2019

-rwxr-xr-x 1 webadmin webadmin 7321 2 de novembro de 2017 servmix_hosts

-rw ------- 1 webadmin webadmin 208 19 de setembro 10:55 test.yml

-rw ------- 1 webadmin webadmin 122 Set 19 10:54 vars.yaml

Não estamos conectados diretamente ao host ... primeiro faça o login em nosso servidor de salto e depois o host ssh ...

o servidor de salto é a porta "vmdcltctws217" usando = 22, tipo de conexão = ssh

e então entrar com nosso UN / PWD

depois disso, fizemos sudo para conexão com o servidor host.

sudo su - easesqa

e então o servidor host ssh como ..

vlddwblasts001.test.intranet

então executamos o comando start / stop a partir daqui ..

Por favor me ajude, para que posso fazer isso?