Файлы, указанные в описании:

• библиотека / ansible / модули / система / group.py

Если эти файлы неточны, обновите раздел описания component name или используйте команду !component bot.

нажмите здесь, чтобы получить помощь по ботам

cc @sfromm
нажмите здесь, чтобы получить помощь по ботам

Я начал получать это предупреждение, но не нашел ни ссылок в руководстве по портированию, ни указаний о том, как и что исправить.

большинство моих предупреждений относятся к ec2.py, где instance_id использовал - (например: i-033f62b586143dff7 ) и регионы (например: eu-central-1c ), поэтому у нас нет реальное исправление для этого

Наконец, это сломало некоторые из моих пьес, где я использовал when: ansible_hostname in groups['varnish'] а ansible_hostname - это varnish-eu-central-1c-001 .
Раньше это работало нормально, теперь мне нужно использовать inventory_hostname чтобы получить varnish_eu_central_1c_001 и найти совпадение с groups['varnish']

Поэтому в руководстве по портированию требуется как минимум и срочно предупреждение о том, что inventory_hostname и groups[] могут возвращать разные данные.

Что послужило причиной удаления тире из названий групп? Мне действительно трудно найти для этого вескую причину, тем более, что это потребует большого объема рефакторинга кода.

@ssbarnea С одной стороны, мы делаем все возможное, чтобы разрешить только имена переменных и другие подобные ключи, которые являются действительными идентификаторами Python. Чтобы объяснить немного подробнее об именах групп, это вызывает проблему у пользователей, пытающихся использовать "точечный синтаксис", такой как groups.foo-group , который не выполняет то, что ожидает пользователь. Количество проблем и запросов на поддержку, вызванных такими небольшими проблемами, заставило нас пойти по пути безопасных имен, чтобы гарантировать, что таких проблем не возникает.

Те, кто хочет сохранить символы, которые мы считаем недопустимыми, могут отказаться от этой функции.

Что мы должны сделать, чтобы отказаться от этой функции? Наши локальные сценарии развертывания Ansible завалены названиями групп, содержащими дефисы. Конечно, мы не используем их с точечной нотацией. Но изменить их все было бы поистине грандиозной задачей. Я бы предпочел отказаться и в то же время посоветовать моей команде избегать использования дефисов в будущем и, где возможно, преобразовывать дефисы в подчеркивания, хотя последняя часть не всегда так проста, как может показаться.

Итак, можно ли просто установить force_valid_group_names = false в ansible.cfg? Это кажется правильным на основе https://github.com/ansible/ansible/commit/d241794daa6d413e6447890e2a4f11e0d818cf0e#diff -fd24ad93fbc32f454761746c1ac908f2

Что мы должны сделать, чтобы отказаться от этой функции? Наши локальные сценарии развертывания Ansible завалены названиями групп, содержащими дефисы. Конечно, мы не используем их с точечной нотацией. Но изменить их все было бы поистине грандиозной задачей. Я бы предпочел отказаться и в то же время посоветовать моей команде избегать использования дефисов в будущем и, где возможно, преобразовывать дефисы в подчеркивания, хотя последняя часть не всегда так проста, как может показаться.

Итак, можно ли просто установить force_valid_group_names = false в ansible.cfg? Это кажется правильным на основе d241794 # diff-fd24ad93fbc32f454761746c1ac908f2

export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=never или export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore - последнего еще нет в документации: https://github.com/ansible/ansible/pull/57318

Спасибо, Джеймс. Поскольку люди обращаются к этой проблеме, чтобы проверить предупреждающее сообщение, я включаю информацию, которая, на мой взгляд, может быть полезной:

Чтобы отключить автоматическое преобразование имени группы ≥2.10 более переносимо / навсегда до тех пор, пока вы не будете готовы удалить недопустимые группы из своего инвентаря, добавьте force_valid_group_names = never в раздел [defaults] INI. ansible.cfg .

Чтобы увидеть все группы и недопустимые символы, которые вызывают предупреждение (возможно, чтобы вы могли настроить таргетинг на них для поэтапного отказа), вы можете сделать что-то вроде этого недоступного CLI no-op:

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

Эти недопустимые символы (по состоянию на 04.06.2019) определены как константа INVALID_VARIABLE_NAMES в:
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
как '^[\d\W]|[^\w]' ,
то есть: any leading non-alpha character OR any character other than alpha-numeric and underscore .
(Надеюсь, я правильно понял)

Если вас раздражают предупреждения об устаревании, вы также можете навсегда отключить их для любой команды ansible- или ansible ad-hoc, добавив deprecation_warnings = False к тому же [defaults] section ansible.cfg , но я бы не рекомендовал этого (поскольку вы можете пропустить важные новости) и вместо этого использовать встроенные переменные среды оболочки, например:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

Однако анализ инвентаря [WARNING] s не исчезнет. Нет конкретной конфигурации или env var для отключения всех предупреждений (пока?), Но если это действительно вас беспокоит, вы можете просто отправить все stderr на /dev/null (вставьте здесь предостережения "передовой практики"):

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

Надеюсь, это кому-то поможет.

Я считаю, что сообщения с предупреждениями об устаревании меня раздражают, только если в них не указан путь миграции. Учитывая, что пространство ограничено и что для исправления, вероятно, потребуется обновление, я бы счел очень полезным предоставить ссылки на тикеты, которые могут документировать решения, обходные пути, ...

Подобный подход мог бы сэкономить дополнительную работу, необходимую для улучшения неполных сообщений с предупреждениями, поскольку нам не нужно было бы обновлять сообщение, а также переносить его на несколько версий назад.

PS. Отключение предупреждений об устаревании - это то, что я бы никому не рекомендовал, может быть, только если проекту уже грозит его окончательная судьба;)

Я начал получать это предупреждение, но не нашел ни ссылок в руководстве по портированию, ни указаний о том, как и что исправить.

большинство моих предупреждений относятся к ec2.py, где instance_id использовал - (например: i-033f62b586143dff7 ) и регионы (например: eu-central-1c ), поэтому у нас нет реальное исправление для этого

Наконец, это сломало некоторые из моих пьес, где я использовал when: ansible_hostname in groups['varnish'] а ansible_hostname - это varnish-eu-central-1c-001 .
Раньше это работало нормально, теперь мне нужно использовать inventory_hostname чтобы получить varnish_eu_central_1c_001 и найти совпадение с groups['varnish']

Поэтому в руководстве по портированию требуется как минимум и срочно предупреждение о том, что inventory_hostname и groups[] могут возвращать разные данные.

Я хотел бы повторить заявление о предупреждении, генерируемом сценарием динамической инвентаризации EC2 . Я заметил, что есть параметр конфигурации ec2.ini для отключения группировки хостов по instance_id ( group_by_instance_id = False ), но параметр, который не устраняет предупреждение для меня, как я ожидал - я убедился, что очистил кеш локального инвентаря.

Какие обходные пути конкретно для динамической инвентаризации EC2?

Эти недопустимые символы (по состоянию на 04.06.2019) определены как константа INVALID_VARIABLE_NAMES в:
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
как '^[\d\W]|[^\w]' ,
то есть: any leading non-alpha character OR any character other than alpha-numeric and underscore .
(Надеюсь, я правильно понял)

Звучит точно для меня. Вы должны отправить PR документа с этой информацией.

Если вас раздражают предупреждения об устаревании, вы также можете навсегда отключить их для любой команды ansible- или ansible ad-hoc, добавив deprecation_warnings = False к тому же [defaults] section ansible.cfg , но я бы не рекомендовал этого (поскольку вы можете пропустить важные новости) и вместо этого использовать встроенные переменные среды оболочки, например:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

Однако анализ инвентаря [WARNING] s не исчезнет. Нет конкретной конфигурации или env var для отключения всех предупреждений (пока?), Но если это действительно вас беспокоит, вы можете просто отправить весь stderr на /dev/null (вставьте здесь предостережения "передовой практики"):

Недокументированная опция ignore обеспечивает эту функциональность. Документы PR здесь: https://github.com/ansible/ansible/pull/57318

Начиная с версии 2.8.2, это предупреждение об устаревании будет подавлено, если вы явно укажете любой из вариантов.

Где команда разработчиков ansible обсуждает такие решения? Нам, пользователям, очень трудно понять причину этого. Если это рассуждения в чистом виде в стиле питона, а не практические, возможно, стоит пересмотреть их? Если тире в именах групп сломает что-то в будущих выпусках ansible, это может быть проблемой с реализацией, а не с именованием группы?

Для меня это больше похоже на косметическое изменение, чем на то, что было должным образом продумано.

Имя группы - это не имя переменной, это ее содержимое. Дефис / тире - это просто символ, который также является чрезвычайно популярным способом группировки информации в соглашении об именах. По сравнению с восклицательным знаком или звездочкой он не имеет особого значения в ограничительном предложении.

Стоимость устранения этой проблемы огромна, учитывая, что тысячам сайтов приходится не только изменять названия групп в инвентаризациях, но и проверять все свои сценарии и домашние роли и снова их все тестировать.

Если у «крестьян» есть хоть какой-то способ сделать так, чтобы их голос был услышан, я бы хотел отбросить свое мнение и попытаться понять, как эта идея возникла.

Я пришел к выводу, что изменение было внесено в доступный, потому что пользователи совершали такие ошибки, как пытались использовать groups.group-name вместо groups['group-name'] . AIUI, это изменение исключительно с целью уменьшения проблем с поддержкой. (Я лично против этого изменения.)

Старое поведение никуда не денется; он просто станет недоступным без явного выбора старого поведения.

Печально слышать.

Мой вариант использования заключается в том, что я встраиваю команду "ansible-inventory" в файл Vagrant таким образом, чтобы было невежливо помещать что-либо в ansible.cfg, и это помогло бы иметь возможность переопределить поведение как параметр командной строки (не переменная среды).

Обычно подобные изменения происходят из-за благих намерений, но не всегда могут привести к желаемому результату.

Моя проблема с этим изменением заключается в том, что имена групп теперь стали несколько "особенными" - тире разрешены в именах хостов, но не в именах групп, что делает его немного странным, учитывая начало сценария в разделе hosts: Я мог написать имена хостов и / или групп.

Действительно ли объяснение, данное @sivel, является единственной причиной этого изменения? А как насчет hosvars['foo-host'] тогда? Я надеюсь, что никто не думает о том, чтобы делать дефисы недопустимыми символами в именах хостов инвентаризации ...
Помимо hostvars существует масса других примеров, в которых нельзя использовать "точечную нотацию", поэтому необходимо знать, когда использовать, какая форма останется. Я считаю довольно произвольным выделять названия групп.

Хотя аргумент с точечной нотацией является в некоторой степени веским оправданием, я не вижу, чтобы это решило ваши проблемы с поддержкой без улучшения документации. Если ваши пользователи делают что-то глупое, вашей документации недостаточно. Все, что удалось разработчикам, - это оттолкнуть множество пользователей. Имена групп я вижу как произвольные строковые значения. Ограничение буквенно-цифровыми символами и подчеркиванием, честно говоря, является своего рода болью, особенно когда в RFC для имени хоста разрешены тире, точки и т. Д. Если бы подчеркивание было фактическим стандартом для соглашений об именах, я не думаю, что это было бы проблемой. Дефисы широко используются для строк дескрипторов. Если вы хотите уменьшить объем поддержки, попробуйте решить проблему с точечной нотацией с другой стороны; создайте сценарий проверки, который может предоставить ваша служба поддержки, который проверяет наличие проблем с передовой практикой и предоставляет предупреждения или рекомендации в качестве примера. Обновите свою документацию о предупреждении о точечной нотации, чтобы она была большой, жирной, красной, мигающей и т.д. Ответьте на звонок, посмотрите проблему, укажите ссылку на документ, готово.

Тире в именах групп являются действительными INI и действительными YAML, я не понимаю, почему я, как пользователь, должен переименовывать все мои группы только потому, что имена не могут использоваться в качестве имен переменных Python?

Также подвергается сомнению обоснование этого решения отказаться от - в именах групп. Невозможность использовать тире в динамическом инвентаре keyed_groups уже достаточно раздражала, но необходимость переименовывать все наши группы в наших файлах инвентаря и командах ansible-playbook -l ... только для того, чтобы избежать гипотетических проблем, связанных с синтаксисом поддержки. будет болезненно.

FWIW у нас есть соглашение для именования групп ролей, например foo_server , и групп узлов, например foo-dev или foo-test . Почти 100% нашего использования Ansible - это команды типа ansible-playbook -l foo-dev , поэтому это изменение потребует больших усилий для борьбы с мышечной памятью.

Не уверен, что добавление сюда еще одного меня 2 будет способствовать отмене этого конкретного решения, но я склонен согласиться с критиками требования, чтобы имена групп были действительными идентификаторами Python.

Пожалуйста, поддерживайте дефисы вместе с буквами, цифрами и подчеркиванием в названиях групп (но я тоже не имею ничего против точек)!

Мы часто используем дефисы в названиях групп. Оба для группировки таких имен:

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

и _abuse_ inventory, чтобы хранить список хостов в одном месте (вместо сохранения имен хостов в разных файлах var), например:

[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%}
{% для хоста в _hostlist%}
...
`` ''

Мы не используем точки только для того, чтобы сделать видимыми различия между именами групп и хостов.

Слово INVALID в TRANSFORM_INVALID_GROUP_CHARS не дает уверенности в том, что их можно продолжать использовать в долгосрочной перспективе.

Если намерение состоит в том, чтобы избежать использования этих символов, лучше называть их символами _UNSAFE_, отображать предупреждение и позволить пользователям решать, видят они это предупреждение или нет. Но никогда не запрещайте и не заменяйте эти символы!

Пользователи должны: а) отключить это предупреждение (используя ключевое слово типа ALLOW_UNSAFE_GROUP_CHARS), б) изменить имена своих групп (если возможно) или в) просто жить с этим предупреждением. Большинство в любом случае выберет один из первых двух вариантов.

Я также считаю, что это бессмысленно, поскольку тире «-» является стандартным разделительным символом, используемым почти во всех типах компьютерных инструментов, и попытки соответствовать одной «религии» кажутся ограничивающими !!!

Старое поведение никуда не денется; он просто станет недоступным без явного выбора старого поведения.

Я бы не был так обеспокоен этим устареванием, если бы действительно можно было отказаться от тире в именах групп. Тогда это будет понятно с точки зрения нового пользователя.

Однако предупреждение об устаревании подразумевает, что опция TRANSFORM_INVALID_GROUP_CHARS=never исчезает в Ansible 2.10, и поэтому нам нужно будет начать переименовывать все наши группы до выпуска Ansible 2.10?

[ПРЕДУПРЕЖДЕНИЕ ОБ УСТАРЕВАНИИ]: настройки TRANSFORM_INVALID_GROUP_CHARS по умолчанию разрешают использование недопустимых символов в именах групп, это изменится, но по-прежнему будет настраиваться пользователем после прекращения поддержки. Эта функция будет удалена в версии 2.10. Предупреждения об устаревании можно отключить, установив deprecation_warnings = False в ansible.cfg.

Кроме того, использование плагина динамической инвентаризации keyed_groups TRANSFORM_INVALID_GROUP_CHARS=never вызывает преобразование имен групп, даже если установлено 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

Желаемое поведение

• Использование TRANSFORM_INVALID_GROUP_CHARS=never необходимо поддерживать в будущем

  РЕДАКТИРОВАТЬ: читая код, похоже, намерение состоит в том, чтобы сохранить TRANSFORM_INVALID_GROUP_CHARS но изменить значение по умолчанию на always в 2.10 - в этом случае предупреждение об устаревании не очень хорошо сформулировано: https: / /github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/inventory/group.py#L50

• Использование TRANSFORM_INVALID_GROUP_CHARS=never должно отключить предупреждение об устаревании

  Кажется, это уже возможно с недокументированным вариантом ignore : https://github.com/ansible/ansible/pull/57318

• Использование TRANSFORM_INVALID_GROUP_CHARS=never также должно разрешать использование тире в динамическом инвентаре keyed_groups

  РЕДАКТИРОВАТЬ: это явно для обратной совместимости с Ansible 2.7, которая безоговорочно преобразовывала сгенерированные имена групп. Было бы здорово иметь явный отказ от этого.

Что касается имен переменных, я не понимаю, почему формат ключа словаря должен быть уравновешен синтаксисом имени переменной? AFAIK ни один язык программирования не имеет такого ограничения. В Python вы можете использовать любую строку в качестве словарного ключа.

Разве «группы» не являются переменной словарного типа, а имена узлов и групп в Ansible являются просто ключами словаря. Они не являются ни свойствами, ни переменными, или нет?

Я бы предпочел запретить синтаксис groups.foo-group, чем groups ["foo-group"]. Если g = "foo-group", то вы используете groups.g или groups [g]?

Использование ansible.cfg [default] force_valid_group_names = ignore или export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore , похоже, не работает в Ansible 2.8.1. Он по-прежнему выдает предупреждение об устаревании.

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

Это потому, что он еще не указан в действительном choices ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Использование ansible.cfg [default] force_valid_group_names = ignore или export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore , похоже, не работает в Ansible 2.8.1. Он по-прежнему выдает предупреждение об устаревании.

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

Это потому, что он еще не указан в действительном choices ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Это ошибка, которая будет исправлена ​​в следующей версии 2.8.2. Вы сможете export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore и все предупреждения будут подавлены.

(Параметр игнорирования все еще не задокументирован: https://github.com/ansible/ansible/pull/57318)

Это сломает всех. Плохое решение.

Есть ли способ поговорить с сопровождающими по этому поводу?

Возможно, кто-нибудь из сопровождающих мог бы здесь немного уточнить, если это просто проблема поддержки или они используют конструкции python, которые действительно ломаются?

Я просто хочу добавить, что это довольно раздражает, и неспособность действительно выяснить проблему также раздражала, мне буквально пришлось сделать ansible-playbook "insert yaml file here" > output.txt чтобы выяснить проблему.

Согласен с большинством плакатов здесь. Удаление дефисов из имен групп кажется плохо продуманным решением или решением, основанным на реализации, а не семантически.

Для меня это изменение не имеет абсолютно никакого смысла. Разработчики Ansible хотят заставить тысячи и тысячи пользователей изменить название своей группы только потому, что им нужен дополнительный синтаксис (а не отсутствующий) для доступа к группам? Это шутка?

В большой настройке мы используем тире и точки.
Наш шаблон product-name.environment.datacenter очень ясен.
Я не могу себе представить, чтобы сбросить - и . поскольку это сделало бы инвентарь полностью нечитаемым.

Мы используем доступные плагины инвентаризации, которые запрашивают локальную CMDB для имен групп, которые содержат (и будут продолжать содержать) тире. Если это станет недействительным в будущем, это приведет к поломке многих вещей.

В большой настройке мы используем тире и точки.
Наш шаблон product-name.environment.datacenter очень ясен.
Я не могу себе представить, чтобы сбросить - и . поскольку это сделало бы инвентарь полностью нечитаемым.

Мы используем аналогичный подход с иерархической схемой именования (на основе java, например, org.company.product-name.component).
Было бы абсолютным ужасом вернуться к подчеркиванию.

хех. мы тоже столкнулись с этой проблемой. мы интенсивно используем тире в именах наших групп.
Если бы можно было объяснить, какие проблемы связаны с использованием тире в dict, я был бы счастлив узнать

Я в основном повторяю то, что говорили другие, но я хотел добавить немного информации. Я думаю, что если это изменение будет реализовано, флаг, разрешающий тире, должен быть сохранен и сохранен. Хотя я понимаю, что Python ожидает подчеркивания, дефисы обычно используются для имен хостов и имен групп хостов. В нашей среде мы динамически генерируем инвентарь из хостов и групп хостов в нашем каталоге LDAP / Kerberos. Я упоминаю об этом, потому что, хотя мы могли бы изменить имена хоста и группы, это нежелательно.

Что мы должны сделать, чтобы отказаться от этой функции? Наши локальные сценарии развертывания Ansible завалены названиями групп, содержащими дефисы. Конечно, мы не используем их с точечной нотацией. Но изменить их все было бы поистине грандиозной задачей. Я бы предпочел отказаться и в то же время посоветовать моей команде избегать использования дефисов в будущем и, где возможно, преобразовывать дефисы в подчеркивания, хотя последняя часть не всегда так проста, как может показаться.

Итак, можно ли просто установить force_valid_group_names = false в ansible.cfg? Это кажется правильным на основе d241794 # diff-fd24ad93fbc32f454761746c1ac908f2

Протестируйте на Ansible 2.8.2, этот параметр INI не работает должным образом, я считаю, это удалит только ПРЕДУПРЕЖДЕНИЕ ОБ УСТАРЕВАНИИ, в то время как я хочу, чтобы Ansible использовал мои группы с тире без жалоб.

Вот результаты без :

[ПРЕДУПРЕЖДЕНИЕ ОБ УСТАРЕВАНИИ]: настройки TRANSFORM_INVALID_GROUP_CHARS по умолчанию разрешают использование недопустимых символов в именах групп, это изменится, но по-прежнему будет настраиваться пользователем после прекращения поддержки. Эта функция будет удалена в версии 2.10. Устаревание
предупреждения можно отключить, установив deprecation_warnings = False в ansible.cfg.
[ВНИМАНИЕ]: недопустимые символы были обнаружены в именах групп, но не заменены, используйте -vvvv, чтобы увидеть подробности

И с настройкой "false" в ansible.cfg:

[ВНИМАНИЕ]: в именах групп были обнаружены недопустимые символы, которые были автоматически заменены, используйте -vvvv, чтобы увидеть подробности.

Использование ansible.cfg [default] force_valid_group_names = ignore или export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore , похоже, не работает в Ansible 2.8.1. Он по-прежнему выдает предупреждение об устаревании.

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

Это потому, что он еще не указан в действительном choices ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Это ошибка, которая будет исправлена ​​в следующей версии 2.8.2. Вы сможете export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore и все предупреждения будут подавлены.

(Параметр игнорирования все еще не задокументирован: # 57318)

Но это просто подавление предупреждений или это позволит нам продолжать использовать тире в группах?
Это не очень понятно.

Я согласен со всеми здесь недоброжелателями.

Это не только нарушает правила игры, но и вносит свой вклад в то, что я называю неразберихой соглашения в анзибле. Теперь имена хостов и имена групп имеют другое соглашение, просто потому, что некоторые изолированные новички сталкиваются с проблемой дефиса в точечной нотации? Угадай, что ? Они все равно будут на нее натыкаться, и эта функция сможет рассердить людей и не решить никаких проблем. Браво.

Имена групп Ansible должны соответствовать именам групп реального мира, которые они представляют.

Если все остальные инструменты вызывают набор хостов my-backend-service почему операторы Ansible должны принудительно переводить это в my_backend_service чтобы удовлетворить правилам именования Python.

Сегодня действительно печальный день ... Когда коллега из JR высказал мне осуждение, я подумал, что команда Ansible ни за что не оторвется от реальности, чтобы сделать такой эгоистичный выбор. Мне очень нравится Ansible за то, что он может делать (с точки зрения пользователя, который не имеет ничего общего с тем, что он написан на Python). Направление здесь, чтобы продвигать стандарты PEP для конечных пользователей, заставляет меня полностью потерять веру в способность основной команды разработчиков Ansible сделать рациональные решения. Я надеюсь, что IBM это исправит.
ИЛИ
Может быть, появится новый блестящий аналог GO, к которому мы сможем перейти.

Поскольку такое поведение, очевидно, очень спорно, я спрашиваю себя, решено ли это и будет ли это реализовано в любом случае?

Я был бы очень признателен за ответ от людей, стоящих за этим решением, и надеюсь на некоторые уточнения, выходящие за рамки «это стандартная вещь для Python».

Поскольку такое поведение, очевидно, очень спорно, я спрашиваю себя, решено ли это и будет ли это реализовано в любом случае?

Я был бы очень признателен за ответ от людей, стоящих за этим решением, и надеюсь на некоторые уточнения, выходящие за рамки «это стандартная вещь для Python».

Я согласен. Совсем недавно проект "вперед" отказался от импозантного предложения (см. Https://github.com/golang/go/issues/32437#issuecomment-512035919), поэтому к таким вещам можно (а иногда и нужно) вернуться и, в конечном итоге, также отступил.

Это также интересная тема и обсуждения, возможно, не только из-за изменения этой функции. Трудно понять, как работает управление Ansible как продуктом. Может быть, кто-то должен принести с собой что-нибудь на https://www.ansible.com/ansiblefest ?

Поскольку многие из нас ломают голову, не понимая, как строка / содержимое переменной / имя группы каким-либо образом может создавать какие-либо проблемы со стилями кодирования python, было бы неплохо получить здесь ответ от сопровождающих, аргументирующих, почему это создает проблема.

Я могу понять, хотят ли они сохранить стиль кодирования для имен и структур переменных, но содержимое массива или переменной?

Вот краткое обсуждение точечной нотации dicts. Можно, но некрасиво. https://stackoverflow.com/questions/16279212/how-to-use-dot-notation-for-dict-in-python

Тот факт, что вокруг этого есть проблемы с поддержкой, на мой взгляд, является проблемой документации, а не функциональностью. Во всяком случае, я бы сказал, что имена групп НЕ должны быть переменными.

Как и тот факт, что это изменение было реализовано до того, как была / доступна какая-либо документация.

Какое влияние окажет это изменение? Нужно ли мне тщательно редактировать все свои ансибл-инвентарь, чтобы в названиях групп не было тире?

@CMoH IMO лучший обходной путь на данный момент - добавить force_valid_group_names = ignore в вашу конфигурацию и запустить ansible 2.8.2 или новее.

@skyscooby , даже это PITA. Дело в том, что невозможно поместить эту строку по умолчанию в /etc/ansible.cfg и использовать локальный ansible.cfg в каталогах playbook для другой конфигурации. Это означает, что все существующие ansible.cfg файлы необходимо изменить.

Или есть способ установить глобальные значения по умолчанию (без добавления другой переменной в пользовательскую среду)?

@Cougar согласился, что этот выбор от Ansible - это PITA ..

Однако ваша проблема не является уникальной для этого параметра ... мы испытали аналогичную боль, и теперь мы не рекомендуем использовать файлы ansible.cfg для каждого проекта, поскольку большинство параметров можно установить с помощью переменных среды, которые переопределяют параметры файла cfg ... поэтому, если проекты для по какой-то неясной причине требуется конкретная настройка, мы просим их использовать метод ENV, который оставляет остальные настройки, которые им не нужно изменять, установленными в соответствии с корпоративными стандартами. Мы создаем базовый контейнер докеров с этой стандартной конфигурацией, и отдельные проекты просто добавляют записи ENV в свой собственный файл Docker, основываясь на своем образе базового контейнера ansible. Все ansible выполняется в контейнере, поэтому мы уверены, что все модули pip, версии ansible и инструменты времени выполнения идентичны от начала до конца.

РЕДАКТИРОВАТЬ: это также дает нам возможность вводить новые версии ansible и контролировать такие проблемы, прежде чем все в компании столкнутся с ними :)

Я покопался.

эта функция изначально была добавлена ​​в PR https://github.com/ansible/ansible/pull/52748 якобы для поддержки запроса функции https://github.com/ansible/ansible/issues/40581

одно описание цели: https://github.com/ansible/ansible/pull/52748#issuecomment -467976473

первая версия ЭТОГО симптома (хотя и по другой причине): https://github.com/ansible/ansible/issues/51844

Чувак, я уже столько раз читал # 52748.

Насколько я понимаю, имена групп ранее были дезинфицированы в плагинах и ядре, и кто-то (по какой-то причине, поскольку мне все еще не совсем понятно почему) решил, что имена групп должны соответствовать соглашениям об именах переменных Python.

Итак, # 52748 отправил канализацию в инвентарь, что ломает вещи для стольких людей. Особенно люди, которые используют разумные соглашения об именах, например, в AWS, Azure и т. Д., Для сопоставления хостов группам.

Если бы мы использовали то же стандартное соглашение об именах для имен хостов, мы наверняка потеряли бы импульс и потеряли пользователей.

Имя группы - это имя, а не переменная. Использование дефисов в именах групп (как и в именах хостов) имеет смысл. Перевод (очистка) не должен выполняться на уровне инвентаря (нами, пользователями), а в лучшем из миров - фактически никогда.

Я действительно не вижу пользы от этого. Обсуждение, кажется, касается также "." и ":", которое некоторым нравится использовать в названиях групп. Лично я ими не пользуюсь, но и вреда в этом не вижу.

Пока облачные провайдеры используют тире в своей метаинформации, мы должны иметь возможность использовать их для группировки. Собственно, это даже не должно быть драйвером. Если мне хочется назвать группу abcde, это не должно быть проблемой. Это очень полезный разделитель.

Однако эта ветка, похоже, не привлекает внимания разработчиков или сопровождающих. Я думаю, что мы говорим для глухих.

Разработчики / сопровождающие: Пожалуйста, разрешите тире в названиях групп!

Чтобы прояснить некоторые заблуждения, часть из них возникла из-за моих ошибок и из-за того, что первоначальные сообщения были неясными, в последних версиях есть исправления некоторых проблем, которые люди продолжают поднимать здесь, другие исправления все еще появляются:

Просто скажу это один раз и ясно: ВЫ ВСЕГДА МОЖЕТЕ ИСПОЛЬЗОВАТЬ ТИРЕ В ИМЕНАХ ГРУПП, а также точки и другие символы, которые теперь считаются «недействительными», но не по умолчанию. Это «по умолчанию» является устаревшим, по умолчанию будет «безопасным» в 2.11, но у вас всегда будет возможность «выбрать» старое поведение.

И чтобы объяснить, как и почему мы сюда попали:

Во-первых, имена групп ВСЕГДА очищались, просто у них были разные несовместимые правила, в зависимости от типа инвентаря, который вы использовали, скрипты были повсюду, форматы YAML и INI делали каждый свое дело. Основным изменением была «централизация и нормализация санитарии», это было решено еще в 2.4, но не было полностью реализовано до 2.8. Намерение состояло в том, чтобы предоставить норму или базовый уровень, который все можно было бы безопасно использовать в Ansilbe, в котором говорилось, что мы признаем, что многие люди используют `` небезопасные '' или `` недопустимые '' символы для переменных, поэтому мы сделали это настраиваемым не только глобально, но и некоторыми из плагины инвентаря.

Первоначальная реализация имела некоторые проблемы и много обсуждений (нет, мы не решаем это скрывать, у нас есть публичные встречи в irc, на которые вы все приветствуете, https://github.com/ansible/community/blob/master /meetings/README.md), и многие отзывы были включены (они также регистрируются, так что вы можете вернуться, чтобы увидеть обсуждения и рассуждения, но чтобы избежать «погружения в корзину журнала», я объясню большинство проблем ниже) . После выхода версии 2.8 мы получили еще один раунд отзывов, и мы исправили некоторые ошибки, например, всегда получали устаревание, а не только при использовании по умолчанию и особенно с формулировкой документации и предупреждений.

• «Почему имена Python?»
  В основном потому, что Ansible использует Python и JInja (который также использует Python), а некоторые виды использования групп (в основном в наших ранних примерах, но также и во многих сторонних примерах) могут создавать ошибки в playbooks, то есть stuff: '{{ groups.gropup-name-with-dash ... }}' или, что еще хуже, group.name.with.dots . Это создает путаницу для многих пользователей, которые хотят использовать функцию Jinja «точечная нотация для доступа к переменным», и поэтому значение по умолчанию должно быть безопасным для всех пользователей. Большинство людей в этом посте могут не согласиться с этим, но это реальная проблема для многих людей и не должна быть «ловушкой», ожидающей новых или старых пользователей Ansible. Те, кто «отказываются», несут ответственность за то, чтобы избежать взлома в других частях Ansible.

• «Что, если бы мне понравилось, что в каждом инвентаре были разные санитарные условия?»
  Что ж, вы все равно можете отключить `` центральную '' очистку и включить ее для вашего конкретного источника инвентаря, самые популярные новые плагины инвентаризации, которые заменяют старые скрипты, имеют опции, добавленные для имитации поведения скрипта, наихудший сценарий, вы все равно можете использовать скрипты инвентаризации.

• «Почему не имена хостов / следующие имена хостов?»
  Как и в случае с группами, санация имен хостов существовала всегда, но не изменилась, к именам хостов предъявляются другие требования, например, возможность разрешения DNS.
  для сетевых подключений или допустимый путь для chroot-подключений. Кроме того, к счастью, практически нет примеров использования имен хостов в точечной нотации, это не было обычной практикой и могло бы стать проблемой, если бы люди внезапно начали их использовать, но, в отличие от имен групп, мы этого избегали до сих пор. Если это станет проблемой в будущем ... Я тоже не вижу хорошего решения.

Обратите внимание, что этот конкретный тикет (недостаточно хорошее описание / информация) - это то, к чему я уже обращаюсь, надеюсь, что скоро исправлю. Что касается остальной части обсуждения, разработчики не используют Github в качестве форума, некоторые тикеты переходят в него, предыдущий тикет, который закрыт и также имеет длинную ветку, игнорировался до недавнего времени, в основном потому, что разработчики отфильтровывают закрытые проблемы и ожидайте обсуждения в IRC списке рассылки или новых проблем.

Я надеюсь, что это решит все основные проблемы, поскольку мы всегда открыты для обсуждения, не стесняйтесь использовать ML или IRC, мы просто избегаем использования github, поскольку это не лучшее место для таких вещей.

Большое спасибо за разъяснения.

Благодарим вас за то, что вы нашли время объяснить, хотя было бы гораздо проще прекратить поддержку точечной нотации и отказаться от этой поддержки в нескольких выпусках. Меньше людей используют это по сравнению с количеством людей, у которых есть недопустимые символы в именах групп. Se la vie

@skyscooby проблема в том, что это делает не Ansible, а Jinja.

Просто скажу это один раз и ясно: ВЫ ВСЕГДА МОЖЕТЕ ИСПОЛЬЗОВАТЬ ТИРЕ В ИМЕНАХ ГРУПП, а также точки и другие символы, которые теперь считаются «недействительными», но не по умолчанию.

Хорошо, это полезно знать, спасибо за разъяснения. Однако пользовательский опыт действительно нуждается в улучшении. У вас есть «проклятие знания». Просто попробуйте представить себя на месте пользователя, который видит это:

[ПРЕДУПРЕЖДЕНИЕ ОБ УСТАРЕВАНИИ]: в настройках TRANSFORM_INVALID_GROUP_CHARS по умолчанию разрешены недопустимые символы в именах групп, это изменится, но по-прежнему будет
настраивается пользователем при прекращении поддержки. Эта функция будет удалена в версии 2.10. Предупреждения об устаревании можно отключить, установив deprecation_warnings = False в ansible.cfg.
[ВНИМАНИЕ]: недопустимые символы были обнаружены в именах групп, но не заменены, используйте -vvvv, чтобы увидеть подробности

Это долгий- долгий путь от

[ПРЕДУПРЕЖДЕНИЕ ОБ УСТАРЕВАНИИ] Имя группы «my-servers» содержит «-», которое станет недействительным по умолчанию из Ansible 2.11. Установите для параметра force_valid_group_names в ansible.cfg или переменной среды ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS значение «ignore», чтобы подавить это. См. Https://docs.ansible.com/something для получения дополнительной информации.

... это то, что я, как пользователь, очень хотел бы увидеть. Это сэкономило бы мне больше часа. Теперь умножьте это на количество людей, которые столкнулись или столкнутся с этой проблемой.

Недопустимые дефисы и точки в именах групп не являются разумным значением по умолчанию. Люди всегда будут иметь их в названиях групп. Требовать, чтобы они установили еще одну переменную в файле конфигурации, чтобы обеспечить разумное поведение, IMHO неоправданно.

Спасибо @bcoca за ваш комментарий выше. Это очень ценится.

Хотя я не доволен решением, я понимаю, что состоялось обсуждение и было принято решение. Если решение все еще открыто для обсуждения, его следует продолжить в списке рассылки или на irc, но это может не отражаться на этом вопросе.

Что касается темы этого выпуска, я хотел бы найти следующую информацию в официальной документации и руководствах по портированию, чтобы быть в курсе этого изменения.

• Какие имена групп действительны по умолчанию?
• Что делать, чтобы продолжать использовать имена групп, включая тире, дефисы, точки и двоеточия?

Потому что мы используем тире во всех именах наших групп и хостов, и мы не будем это менять. Поэтому мне приходится подписываться и менять свой ansible.cfg каждый раз, когда я настраиваю новую установку / среду. Это прискорбно для меня, но я должен как-то с этим справиться. По крайней мере, я ожидал, что это задокументировано соответствующим образом.

Чтобы продолжить обсуждение того, разумно ли это изменение или нет, я открыл ветку в группе разработчиков Ansible.

С наилучшими пожеланиями,
Тронда

Я хочу поблагодарить всех участников по этой проблеме. Основываясь на том, что я здесь прочитал, я решил написать сообщение в блоге https://docs.sbarnea.com/ansible/naming-hosts-and-groups - надеюсь, в нем будет обобщено, что нужно делать пользователям.

@ loop-evgeny Я согласен с тем, что у нас, как у основной команды, есть «проклятие знаний», которое мешает нам создавать полезные для всех документы и ошибки. Мы также полностью полагаемся на сообщество, которое поможет нам сформировать ansible и сделать его простым для как можно большего числа пользователей, поэтому, когда у людей есть рекомендации по улучшению наших документов и наших сообщений об ошибках / предупреждениях, я всегда призываю их помочь нам, отправив pullrequest. Сообщение, на которое вы указываете, содержится в следующем файле, и мы будем очень признательны, если вы отправите нам PR с предлагаемым изменением ...

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

@jctanner Обычно я был бы рад отправить PR, чтобы улучшить бесплатную и полезную программу, которую я использую. Тем не менее, общее отношение разработчиков Ansible к удобству использования, их стремление закрыть как «работающие по назначению» проблемы, которые я считаю самоочевидными ошибками (даже если ошибки дизайна), и тот факт, что в настоящее время Ansible имеет 2025 г. (это две тысячи !) открытый PR дает мне очень мало уверенности в том, что моя работа не пропадет зря. Если вы действительно хотите, как вы говорите, «полагаться на сообщество», то, ИМХО, необходимо существенное изменение культуры.

Хм .. Этот шанс меня тоже поразил.

К сожалению, мы используем имена сетей в качестве имен групп, и это нелегко изменить. Я бы с удовольствием отказался от сахара точечного синтаксиса для имен групп, поскольку я никогда не использовал его (хотя я использую его с другими переменными).

В будущем было бы предпочтительнее использовать ansible-playbook whatever.yaml -l some.network.to.use . Использование любого другого имени, кроме сети, в качестве имени группы значительно сократит использование.

Привет,
Я немного запутался в данный момент. Может ли кто-нибудь сказать мне, что я должен установить в ansible.cfg чтобы в будущем разрешить недопустимые символы в именах групп?

force_valid_group_names = ignore

Какая будет будущая версия обновления Ansible для решения этих проблем? Будет ли когда-нибудь ansible отклонять все тире в имени группы, не пытаясь обойтись без использования force_valid_group_names ? (без получения отзывов от пользователей, которые пострадали от изменения и никогда не сталкивались с проблемами, используя дефис в названиях групп)

Извините. Просто прочтите комментарии от @bcoca и рад видеть, что я смогу использовать дефис, если захочу в будущем - этого для меня достаточно.

Привет,
Я вижу такое же предупреждение, но я не понимаю, что мне следует изменить, и следует ли это менять.
Это что-то связано с питоном?
Как разрешить?

Если я проигнорирую с помощью force_valid_group_names = ignore, это будет с необходимостью, а когда я обновлюсь до Ansible> = 2.10?

С уважением,
Сезар Хорхе

Если я понимаю , это правильно. Единственное, что устарело, - это автоматическое преобразование имен групп. Это означает, что вполне нормально установить force_valid_group_names = ignore после 2.10 и выше.

Также должно быть совершенно нормально продолжать использовать тире и все, что вы хотите, в именах групп. Чего Ansible не будет делать в будущем, так это их санации, чтобы вы могли использовать точечную нотацию даже для «недействительных» имен групп. Например:

Ваш инвентарь содержит группу с именем foo-bar.xyz . Теперь вы хотите написать шаблон, который создает список хостов, принадлежащих этой группе:

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

Имейте в виду, что следующая версия шаблона не будет работать:

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

Это потому, что - и . в этом случае имеют особое значение. Однако точечная нотация будет вполне подходящей, если ваша группа будет иметь имя foo_bar_xyz потому что тогда шаблон будет выглядеть следующим образом:

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

Что, конечно, совершенно нормально.

Стремясь упростить жизнь пользователям, Ansible, по-видимому, всегда исправлял имена групп. Это означает, что было (и до 2.10 все еще возможно) использовать foo_bar_xyz в приведенных выше примерах, даже если группа на самом деле называется foo-bar.xyz . Лично я не думаю, что это вообще упрощает задачу, и похоже, что основная команда теперь также согласна с этим.
Поэтому их следующая попытка решить эту проблему - сделать невозможным наличие «недействительных» имен групп. Однако, насколько я понимаю, всегда можно будет отказаться от этого ограничения, установив force_valid_group_names = ignore .

Короче говоря, на самом деле это два разных изменения, которые были переплетены [1] друг с другом. Отсюда непонятное название и формулировка предупреждения.

Опять же, это только то, как я понимаю проблему. Пожалуйста, поправьте меня, если я ошибаюсь!

[1] для получения дополнительных сведений см. RFC1925, параграф 2, пункт (5).

Я просто хотел оставить свои 2 ¢, так как я твердо стою на стороне тире> подчеркивания. Просто сделав быстрый поиск в Google по этому вопросу , почти всегда подчеркивание помечается как более низкое, чем тире для любого вида путей и меток. С ними также труднее работать во многих текстовых редакторах и файловых системах.

Даже если бы это было не так, тот факт, что я вижу тире, используемые для таких вещей, как метки серверов и группы в дикой природе, намного чаще, чем подчеркивания, означает, что это будет еще одна вещь, которую я должен обязательно добавить ко всем своим и файлы ansible.cfg моих клиентов (я обычно использую по одному на каждую книгу).

У меня нет проблем с тем, что Ansible пытается установить более строгие значения по умолчанию, где он улучшает опыт, но сначала вы пришли за черточками в именах моих ролей (и иногда допускали отдельные исключения для более старых ролей, которые были унаследованы), затем вы пришли за черточками в мои коллекции (они не допускаются ни в каком виде, ни по форме, ни по форме), и теперь вы пришли за черточками в моем инвентаре!

Это война против тире ... и я хочу где-то провести черту - в данном случае это единственное место, где мне фактически невозможно запретить людям использовать тире, поскольку многие поставщики динамического инвентаря создают группы на основе в именах серверов и метках, и многие (если не большинство) организаций, кажется, маркируют вещи с помощью тире (например, us-east-1a , а не us_east_1a ).

Неинтересно иметь значение по умолчанию, которое почти всегда необходимо переопределить, чтобы программное обеспечение работало, но похоже, что в Ansible 2.11 так и будет.

Если это все потому, что некоторые пользователи, незнакомые с Jinja2 и Python, не понимают, что something.with-some-dashes недействителен, я бы поспорил, что лучше научить их «если есть тире, вы должны использовать обозначение скобок для доступа к dict, например something['with-some-dashes'] . Вы можете даже смешать их, если необходимо. Это не очень чисто и целостно, но мы здесь не все разработчики Rust ...

Очень хорошо сказано, Джефф. Я полностью с вами согласен - это изменение будет настолько разрушительным и потребует не только разовой миграции, но и изменит рабочий процесс огромного количества пользователей. Ansible больше не будет работать "из коробки".

Имена хостов не могут включать подчеркивание, поэтому в нормальном мире inventory_hostname не будет обязательным. Это означает, что наши реестры теперь будут выглядеть совершенно непоследовательно, с именами хостов, которые не могут содержать подчеркивания, и группами, которые не могут содержать дефисы.

Пожалуйста, только не меняйте значение по умолчанию.

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

Привет,
Я полностью согласен с Джеффом здесь .

Но, как указано выше в @bcoca, большинство разработчиков не смотрят на эти обсуждения здесь на регулярной основе, и этот вопрос может быть неподходящим местом для обсуждения изменения, потому что он касается правильной документации.

Для обсуждения присоединяйтесь к теме. Изменение настройки TRANSFORM_INVALID_GROUP_CHARS по умолчанию - хорошая идея? в группах Google.

Отличные очки Джефф.

Неинтересно иметь значение по умолчанию, которое почти всегда необходимо переопределить, чтобы программное обеспечение работало, но похоже, что в Ansible 2.11 так и будет.

Это для меня главный вывод из всех этих обсуждений. Я понимаю проблему, которую необходимо решить, но решение, похоже, противоположно тому, что нужно. Это упрощает поддержку, но усложняет работу пользователей - это обратное решение.

Если это все потому, что некоторые пользователи, незнакомые с Jinja2 и Python, чего-то не понимают. With-some-dashes недействителен, я бы поспорил, что лучше научить их «если есть тире, вы должны использовать скобки для доступа к dict, например something ['with-some-dashes']. Вы можете даже смешать их, если необходимо.

Это лучшее решение, не ломающее вещи, которые использовались годами.

Отличный комментарий от @geerlingguy - на

Я хотел бы добавить, что как пользователь Ansible, зачем мне знать, что такое действительный синтаксис Python? Я давно использую Ansible и понимаю, что Ansible (и его модули) написаны на Python, но зачем мне это нужно? Предоставление этого факта конечному пользователю - просто плохой дизайн.

Подобно разрешению только допустимой нотации JavaScript / Ruby / .NET / любой другой для таких вещей, как имена пользователей в веб-приложении. Почему конечному пользователю важно, на каком языке написано приложение?

Кроме того, введение критических изменений - сложная тема, я стараюсь этого избегать, если это возможно. Если мне нужно внести изменения, я обычно оставляю старое существующее поведение по умолчанию и позволяю людям соглашаться на новое поведение. Почему этого не сделали здесь? Почему мне нужно либо изменить мою конфигурацию, либо, что еще хуже, весь мой инвентарь? Почему не наоборот?

Если системе требуются строго совместимые токены внутри, то система должна внутренне сгенерировать токены и создать таблицу поиска, которая связывает внутренние токены с данными пользователя. Таким образом, Ansible может изменять свои правила токенов по мере необходимости и ограничивать влияние на пользователей. Пользователи должны иметь возможность называть свой инвентарь, роли и т. Д. Так, как они или их клиенты считают нужным.

Мне кажется, что это изменение может иметь эффект, противоположный предполагаемому (уменьшение количества запросов в службу поддержки):

Теперь нет разделителей, поддерживаемых (по умолчанию) как именами хостов (которые должны быть разрешаемыми в DNS, т. Е. Не содержать подчеркивания), так и именами групп (которые не должны содержать тире).

Определенно должно быть свободно называть любые хосты

El mié., 14 лет назад. 2019 16:16, Кристиан Пойнтнер [email protected]
написать:

Если я понимаю это
https://github.com/ansible/ansible/issues/56930#issuecomment-516863432
правильно. Единственное, что устарело, - это автоматический
преобразование названий групп. Это означает, что можно полностью установить force_valid_group_names
= игнорировать после 2.10 и позже.

Также должно быть совершенно нормально продолжать использовать тире и все, что вы
не указаны в названиях групп. Чего Ansible не будет делать в будущем, так это санации
их, поэтому вы можете использовать точечную нотацию даже для «недопустимых» имен групп. Для
пример:

В вашем инвентаре есть группа с именем foo-bar.xyz. Теперь ты хочешь написать
шаблон, который создает список хостов, принадлежащих к этой группе:

{% для хоста в группах ['foo-bar.xyz']%}
{{ хозяин }}
{% endfor%}

Учтите, что эта версия шаблона работать не будет:

{% для хоста в groups.foo-bar.xyz%}
{{ хозяин }}
{% endfor%}

Это потому, что - и. в этом случае имеют особое значение. В
пунктирная нотация, однако, была бы вполне приемлемой, если бы ваша группа имела
назовите foo_bar_xyz, потому что тогда шаблон будет выглядеть так:

{% для хоста в группах.foo_bar_xyz%}
{{ хозяин }}
{% endfor%}

Что, конечно, совершенно нормально.

Стремясь упростить жизнь пользователям, Ansible, по-видимому, всегда
сделал некоторую санацию для названий групп. Это означает, что это было (и до 2.10
все еще есть) можно использовать foo_bar_xyz в приведенных выше примерах, хотя
группа на самом деле называется foo-bar.xyz. Лично я так не думаю
упрощает все, и кажется, что основная команда теперь также согласна
с этим.
Поэтому их следующая попытка решить эту проблему - сделать невозможным
"недопустимые" названия групп в первую очередь. Однако насколько я понимаю
всегда можно будет отказаться от этого ограничения, установив force_valid_group_names
= игнорировать.

Короче говоря, на самом деле произошли два разных изменения.
переплетены [1] друг с другом. Отсюда сбивающее с толку название и формулировка
предупреждение.

Опять же, это только то, как я понимаю проблему. Пожалуйста, поправьте меня, если я
неправильный!

[1] для получения дополнительных сведений см. RFC1925.
http://www.faqs.org/rfcs/rfc1925.html абзац 2, пункт (5)

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/ansible/ansible/issues/56930?email_source=notifications&email_token=AA5N2CJCIELW7JWHC6OJ35DQEQHSPA5CNFSM4HPRGLKKYY3PNVWWK3TUL52HS4DNMVREXG4
или отключить поток
https://github.com/notifications/unsubscribe-auth/AA5N2CIVT5PLD2QCAGGBK6LQEQHSPANCNFSM4HPRGLKA
.

На мой взгляд, это действительно неправильное решение. И по неправильной причине. Действительно, сокращение количества обращений в службу поддержки?

Ansible, как инструмент, не должен навязывать конечному пользователю детали, зависящие от языка. Я уже так расстроен тем, что Terraform навязывает мне весь этот Голанг в глотку, теперь то же самое происходит здесь с Ansible и «питоническим» стилем. Не поймите меня неправильно, я неплохо работаю и с Go, и с Python, но когда дело касается инфраструктуры как кода, почему меня это должно волновать? И что случилось с обещанием, что YAML будет определять форму кодовой базы для управления? «Инфраструктура как данные, которые вы можете читать и запускать», я слышал это много раз ... Насколько я знаю, YAML вообще не заботится ни о дефисах, ни о подчеркивании.

Кстати, существует довольно много вещей, не поддерживающих подчеркивания. Имена хостов, регионы AWS и идентификаторы буквально для всего, просто чтобы упомянуть некоторые действительно важные. Удачи в сохранении всех исключений, где преобразование не должно происходить ...

Людям, которые приходят сюда просто в поисках быстрого решения, как избавиться от этого, просто добавьте строку force_valid_group_names = ignore в свой ansible.cfg и будьте счастливы.

Насколько я понимаю, вы в любом случае не можете использовать точечную нотацию для переменных с пробелами, и хотя я никогда не создаю переменные с пробелами, к сожалению, множество поставщиков возвращают ключи словаря с пробелами через ответы json API. На мой взгляд, разумным вариантом было бы перейти на использование квадратных скобок. Надеюсь, установка force_valid_group_names на игнорирование не вызовет негативных последствий в дальнейшем, кто знает, что еще запланировано в будущем с этим изменением.

Это довольно ужасное решение, особенно когда речь идет о работе с динамическими инвентаризациями, такими как Openstack (и AWS).
Имена экземпляров и ключи метаданных, содержащие «запрещенные символы», часто возвращаются как элементы инвентаря и / или групповые переменные из базового облака. Это превратит жизнь многих администраторов Openstack (и AWS) в ад, пытающихся управлять своими флотами, используя метатеги и / или идентификаторы экземпляров, например:
instance-8ca09c33-f255-440f-9544-b0ab318c79d9
meta-os_ubuntu

Разработчики Ansible должны серьезно @geerlingguy . Он является одним из крупнейших участников Ansible Galaxy, и его роли используются множеством людей. Я думаю, что это изменение действительно плохо для людей, у которых есть тысячи хостов с именами вроде: $env-$role-[0..99] . Неужели мы должны все переименовать, чтобы успокоить наших повелителей Ansible?

@ssbarnea С одной стороны, мы делаем все возможное, чтобы разрешить только имена переменных и другие подобные ключи, которые являются действительными идентификаторами Python. Чтобы объяснить немного подробнее об именах групп, это вызывает проблему у пользователей, пытающихся использовать "точечный синтаксис", такой как groups.foo-group , который не выполняет то, что ожидает пользователь. Количество проблем и запросов на поддержку, вызванных такими небольшими проблемами, заставило нас пойти по пути безопасных имен, чтобы гарантировать, что таких проблем не возникает.

Те, кто хочет сохранить символы, которые мы считаем недопустимыми, могут отказаться от этой функции.

Как долго пользователи смогут отказаться от этого поведения? Будет ли постоянная опция конфигурации для отключения этого поведения во всех будущих версиях ansible, или оно будет поддерживаться только до 2.11? Я был бы рад, если этот параметр будет включен по умолчанию, если у меня всегда есть возможность отключить его.

Если это станет жестким ограничением в 2.11+, то вы, вероятно, потеряете клиентов, которые связаны ограничениями своей организации (не все пользователи ansible имеют право диктовать соглашения об именах, используемые их компанией). Похоже, что это изменение также станет серьезной проблемой для тех, кто использует ansible для управления облачной инфраструктурой, где часто используются тире.

Напомню тем, кто еще не прочитал здесь всю ветку. В списке рассылки разработчиков также есть ветка: https://groups.google.com/forum/#!topic/ansible -devel / bjAcM9ferIw

ИМХО, это изменение было действительно плохим выбором. Изменения синтаксиса взлома кода в младших версиях выпуска удерживают нас от расширения использования Ansible в нашей среде. Потому что я не смогу обновить Ansible, если он нарушит правила игры моих пользователей.

Но, как указано выше в @bcoca, большинство разработчиков не смотрят на эти обсуждения здесь на регулярной основе, и этот вопрос может быть неподходящим местом для обсуждения изменения, потому что он касается правильной документации.

@Tronde : можно утверждать, что с участниками И клиентами консультируются перед написанием историй, чтобы понять влияние и собрать отзывы задолго до того, как кто-то закодирует решение. Как уже упоминалось здесь, это провал управления продуктом, который мы видели не раз.

@Andyfeller описывает это изменение в качестве примера:

У нас есть проблема с этим на нашем сайте.

Мы используем Red Hat Identity Manager в качестве внешнего инвентаря, мы его не контролируем, он содержит множество групп хостов с дефисами вместо подчеркиваний. Это не будет изменено (из-за всего прочего, что существует с этими именами).

Итак, нам понадобятся:

• Чтобы настроить Ansible для поддержания текущего поведения
• Отключить предупреждение об устаревании
• Сделайте это для командной строки Ansible и Ansible Tower

FYI PR https://github.com/ansible/ansible/pull/66650 (пожалуйста, никаких вил) намечен на 2.10 (на текущий момент), что означает, что любой, кто в настоящее время видит это предупреждение, будет (после обновления до 2.10, опять же, предполагая, что PR объединен) вместо этого начинаются сбои playbook (пока они не установят force_valid_group_names = ignore в ansible.cfg ).

Просто для наглядности. Я все еще твердо поддерживаю свое более раннее утверждение, что это враждебное пользователю значение по умолчанию, поскольку все еще существует множество сценариев динамической инвентаризации (некоторая часть самого Ansible или теперь перемещена в `` официальные '' коллекции), которые генерируют имена групп с тире или другие допустимые символы DNS.

Практически любой, кто использует Ansible с AWS, должен будет изменить значение по умолчанию.

@geerlingguy Это правильный PR #? Похоже, это указывает на эту проблему.

К вашему сведению, это обсуждалось на основной встрече здесь , начиная с 19:06:55

@ apple4ever упс, обновил ссылку, это https://github.com/ansible/ansible/pull/66650

Итак, я видел выше много комментариев о вещах, на которые уже были даны ответы / опровергнуты / и т. Д., Так что просто свяжу здесь свой предыдущий пост.

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

Пожалуйста, не добавляйте новые сообщения, которые не добавляют НОВЫХ пунктов для обсуждения, поскольку они скрывают предыдущие, на которые уже был дан ответ.

Кстати, где было бы хорошее место для ссылки в документации Python о том, как выглядят допустимые имена переменных? Там https://docs.python.org/3/reference/lexical_analysis.html#grammar -token-identifier, но он не очень удобен для пользователя и не читается для людей без опыта работы в области компьютерных наук.

Причина, по которой я спрашиваю, заключается в том, что я не уверен, действительно ли рассматривалась первоначальная жалоба. Есть просто предупреждение о том, что что-то не так, но нужно много покопаться, чтобы выяснить, что именно и как можно - при желании или возможности - на самом деле выбрать допустимое имя группы. Я ожидал бы по крайней мере четкого «Имя группы foo-bar содержит недопустимые символы ( - ). Допустимые имена групп должны быть действительными идентификаторами Python (см. https://docs.python.org/??? для получения дополнительной информации)» сообщение, а не просто «есть плохие символы, проверьте еще раз с -vvvv, чтобы узнать, какие именно!». В идеале это также должно было бы упомянуть, что это можно отключить, но это может привести к другим неожиданным проблемам (например, из-за того, что Ansible будет очень сложно различать группы foo-bar , foo.bar и foo_bar ).

В настоящее время это больше похоже на сообщение «Вы сделали что-то не так, исправьте» без четкого указания, как действовать, что также могло способствовать сильному отклику здесь.

@geerlingguy написал в комментарии 56930 :

(пока они не установят force_valid_group_names = false в ansible.cfg)

В документации не упоминается «false» как допустимое значение для этого ключа. Я установил значение «игнорировать», что должно помочь. Но является ли false недопустимым ключевым словом или оно правильное и документация здесь не полная?

@bcoca в предыдущем комментарии:

Просто скажу это один раз и ясно: ВЫ ВСЕГДА МОЖЕТЕ ИСПОЛЬЗОВАТЬ ТИРЕ В ИМЕНАХ ГРУПП, а также точки и другие символы, которые теперь считаются «недействительными», но не по умолчанию. Это «по умолчанию» является устаревшим, по умолчанию будет «безопасным» в 2.11, но у вас всегда будет возможность «выбрать» старое поведение.

Вы неоднократно заявляли, что текущее поведение можно сохранить, но каковы точные настройки ansible.cfg, необходимые для этого _now_ и подавить предупреждение об устаревании.

Я пробовал, как написал @geerlingguy в комментарии 56930:

(пока они не установят force_valid_group_names = false в ansible.cfg)

Это приводит к сбою моих playbooks, когда он не может найти хосты или группы с дефисами (они поступают из плагина инвентаризации, который мы написали BTW, тезисы тоже должны выполнять преобразование, или это делается, когда Ansible принимает инвентарь из плагин?)

Я пробовал, как написал @geerlingguy в комментарии 56930:

(пока они не установят force_valid_group_names = false в ansible.cfg)

Это приводит к сбою моих playbooks, когда он не может найти хосты или группы с дефисами (они поступают из плагина инвентаризации, который мы написали BTW, тезисы тоже должны выполнять преобразование, или это делается, когда Ansible принимает инвентарь из плагин?)

Об этом упоминалось в нескольких комментариях и есть в документации . Вы должны использовать never или ignore .

Так что, мы просто не должны больше использовать скрипт динамической инвентаризации EC2, поскольку он группирует все по «us-east-1», «us-east-2» и т. Д.? Или есть план его обновить? Я просто зашел в документацию Ansible для скрипта динамической инвентаризации EC2, и ссылка для его загрузки на Github больше не работает, так что это интересно.

Я просто зашел в документацию Ansible для скрипта динамической инвентаризации EC2, и ссылка для его загрузки на Github больше не работает, так что это интересно.

См. Https://github.com/ansible/ansible/issues/68419

для тех из вас, кто не утруждает себя чтением журнала IRC, вот решение, то есть никакого решения:

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

да, кто-то написал "не стесняйтесь заходить через ML или IRC". нет, «этот проект - не демократия».

да, кто-то написал "не стесняйтесь заходить через ML или IRC". нет, «этот проект - не демократия».

Честно говоря, это неправильно с открытым исходным кодом - если он ведет к непопулярному способу - люди могут его форкнуть, можно ли его форкнуть?

Я вижу, что принятие PR в ансибле ужасно медленно. Патчи выглядят очевидно необходимыми и простыми изменениями, но они никогда не попадают в него. К счастью, сам ansible гибок, позволяя людям использовать собственные плагины, однако он кажется устаревшим, поэтому я буду меньше вкладывать в него вклад - или даже больше хлопот сделать это.

Мне немного грустно, правда ...

@ sunshine69 Я чувствую твою боль. Но это обсуждение, которое следует провести в IRC или в Google Group for Ansible Development.

Этот выпуск не подходит для этого. Потому что здесь мало кто читает.

@ sunshine69 Я чувствую твою боль. Но это обсуждение, которое следует провести в IRC или в Google Group for Ansible Development.

Этот выпуск не подходит для этого. Потому что здесь мало кто читает.

Хотя обсуждение может быть более продуктивным в этих других каналах, прозрачность ценится специально для тех, кто следит за этим вопросом. В конце концов, IRC предпочитают не все.

К вашему сведению: удаление устаревших данных для TRANSFORM_INVALID_GROUP_CHARS было объединено вчера. Есть PR backport для 2.9 (https://github.com/ansible/ansible/pull/69487) и 2.8 (https://github.com/ansible/ansible/pull/69488), чтобы удалить там предупреждения об устаревании.

Файлы, указанные в описании:

• lib/ansible/modules/group.py

Если эти файлы неверны, обновите раздел описания component name или используйте команду !component bot.

нажмите здесь, чтобы получить помощь по ботам

Когда я установил force_valid_group_names = ignore ПРЕДУПРЕЖДЕНИЕ исчезло, но УВЕДОМЛЕНИЕ ОБ УСТАРЕНИИ не

Наконец, в документации я нашел: force_valid_group_names = silently который выполнит замену и не засоряет вывод - если это то, что вы хотите сделать.

Тем не менее, всей этой проблемы можно было бы избежать, если бы бессмысленные изменения, подобные этой, не были внесены в первую очередь.

@ emmm-dee - Для этой конкретной проблемы я открыл https://github.com/ansible/ansible/issues/70908 - обратите внимание, что эта проблема все еще сохраняется, поскольку до сих пор нет официальной документации о том, какие _are_ 'действительные' групповые символы .

спасибо @geerlingguy за ваши действия! Вы тот, кто делает ансибль лучше.

Я работаю над нашим приложением для отказов (запуск / остановка), но я не связан с хостом приложения.

Я попробовал команду ping, которую вы отправили, и она работает ...

[ webadmin @ vlodjumpts00 ~] $ ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56 (84) байтов данных.

64 байта из 8.8.8.8: icmp_seq = 1 ttl = 112 time = 10,6 мс

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

-bash: mirrorlist.centos.org: команда не найдена

Я хочу использовать это для нашей организации .. если я выполнил команду "ansible all -m ping". столкнувшись с ошибкой, ниже приведены подробности:

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

изменить, но по-прежнему настраиваться пользователем после прекращения поддержки. Эта функция будет удалена в версии 2.10. Предупреждения об устаревании могут быть

отключено установкой deprecation_warnings = False в ansible.cfg.

RTE3EPAdmin | Недостижимо! => {

"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 | УСПЕХ => {

"ansible_facts": {

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

},

"changed": false,

"ping": "pong"

}

Пожалуйста, помогите мне ... что мне нужно для этого. На самом деле у нас нет файла UN / PWD для hosts для подключения хост-машины.

локальный хост ansible_connection = локальный

[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: дети]

RTE3VFO

RTE3EP

RTE3RES

RTE3ORCH

RTE3EASE

RTE3RTS

и структура каталогов:

[ webadmin @ vlodjumpts00 ansible ] $ pwd

/ etc / ansible

[ webadmin @ vlodjumpts00 ansible ] $ ll

всего 84

-rw ------- 1 webadmin webadmin 607 12 июля 2017 г. 1

-rw-r - r-- 1 webadmin webadmin 17910 19 сен 09:55 ansible.cfg

-rw-r - r-- 1 root root 19985 8 декабря 2019 ansible.cfg.rpmnew

-rw ------- 1 webadmin webadmin 213 3 июля 2017 easyasr-rte2-easy.yml

-rwxr-xr-x 1 webadmin webadmin 1034 19 сен 09:16 легкость-хосты

-rwxr-xr-x 1 webadmin webadmin 1647 19 сентября 10:50 хосты

-rw ------- 1 webadmin webadmin 2679 3 июля 2017 г. hosts.bkp

-rw ------- 1 webadmin webadmin 273 6 июля 2017 г. lineinsfile_tst.yml

drwx ------ 4 webadmin webadmin 4096 2 ноября 2017 playbooks

drwxr-xr-x 3 root root 19 Dec 8 2019 роли

-rwxr-xr-x 1 webadmin webadmin 7321 2 ноября 2017 г. servmix_hosts

-rw ------- 1 webadmin webadmin 208 19 сен 10:55 test.yml

-rw ------- 1 webadmin webadmin 122 19 сентября 10:54 vars.yaml

Мы не подключены напрямую к хосту ... сначала войдите на наш сервер перехода, а затем на хост ssh ...

сервер перехода - порт "vmdcltctws217" с использованием = 22, тип подключения = ssh

а затем войдите с нашим UN / PWD

после этого мы сделали sudo для подключения к хост-серверу ..

судо су - easesqa

а затем хост-сервер ssh, например ..

vlddwblasts001.test.intranet

затем мы запускаем команду start / stop отсюда ..

Пожалуйста, помогите мне, для чего я могу это сделать?