In der Beschreibung identifizierte Dateien:

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

Wenn diese Dateien ungenau sind, aktualisieren Sie bitte den Abschnitt component name der Beschreibung oder verwenden Sie den Bot-Befehl !component .

Klicken Sie hier für Bot-Hilfe

cc @sfromm
Klicken Sie hier für Bot-Hilfe

Ich begann, diese Warnung zu erhalten, fand jedoch keine Hinweise im Portierungshandbuch und keine Hinweise, wie oder was zu beheben ist.

Die meisten meiner Warnungen stammen von der ec2.py, wo die instance_id die - (zB: i-033f62b586143dff7 ) und die Regionen (zB: eu-central-1c ) verwendet, also haben wir keine echte Lösung für diese

Schließlich hat dies einige meiner Playbooks kaputt gemacht, wo ich when: ansible_hostname in groups['varnish'] und das ansible_hostname varnish-eu-central-1c-001 .
In der Vergangenheit hat das gut funktioniert, jetzt muss ich inventory_hostname , um varnish_eu_central_1c_001 bekommen und ein Match gegen die groups['varnish']

Dies erfordert also zumindest und dringend eine Warnung im Portierungsleitfaden, dass inventory_hostname und groups[] möglicherweise unterschiedliche Daten zurückgeben

Was war der Grund dafür, den Bindestrich von den Gruppennamen wegzulassen? Es fällt mir wirklich schwer, einen guten Grund dafür zu finden, zumal dies viel Code-Refactoring erfordert.

@ssbarnea Zum einen machen wir einen Push, um nur Variablennamen und andere ähnliche Schlüssel zuzulassen, die gültige Python-Bezeichner sind. Um etwas mehr über Gruppennamen zu erklären, verursacht dies ein Problem für Benutzer, die versuchen, die "Punktsyntax" wie groups.foo-group , was nicht das tut, was der Benutzer erwartet. Die Anzahl der Probleme und Supportanfragen, die durch kleine Probleme wie diese verursacht werden, hat uns dazu veranlasst, einen Weg zu Sicherheitsnamen zu gehen, um sicherzustellen, dass solche Probleme nicht auftreten.

Für diejenigen, die die aus unserer Sicht ungültigen Zeichen beibehalten möchten, können Sie diese Funktion deaktivieren.

Was müssen wir tun, um diese Funktion zu deaktivieren? Unsere lokalen Ansible-Bereitstellungsskripts sind übersät mit Gruppennamen mit Bindestrichen. Wir verwenden sie natürlich nicht mit Punktnotation. Aber sie alle zu ändern, wäre eine wahrhaft monumentale Aufgabe. Ich würde es vorziehen, mich abzumelden und gleichzeitig mein Team zu ermutigen, in Zukunft keine Bindestriche mehr zu verwenden und Bindestriche nach Möglichkeit in Unterstriche umzuwandeln, obwohl dieser letzte Teil nicht immer so einfach ist, wie es scheint.

Setzt man also einfach force_valid_group_names = false in ansible.cfg ? Das scheint richtig zu sein basierend auf https://github.com/ansible/ansible/commit/d241794daa6d413e6447890e2a4f11e0d818cf0e#diff -fd24ad93fbc32f454761746c1ac908f2

Was müssen wir tun, um diese Funktion zu deaktivieren? Unsere lokalen Ansible-Bereitstellungsskripts sind übersät mit Gruppennamen mit Bindestrichen. Wir verwenden sie natürlich nicht mit Punktnotation. Aber sie alle zu ändern, wäre eine wahrhaft monumentale Aufgabe. Ich würde es vorziehen, mich abzumelden und gleichzeitig mein Team zu ermutigen, in Zukunft keine Bindestriche mehr zu verwenden und Bindestriche nach Möglichkeit in Unterstriche umzuwandeln, obwohl dieser letzte Teil nicht immer so einfach ist, wie es scheint.

Setzt man also einfach force_valid_group_names = false in ansible.cfg ? Das scheint richtig zu sein basierend auf d241794#diff-fd24ad93fbc32f454761746c1ac908f2

export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=never oder export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore -- letzteres ist noch nicht in der Dokumentation: https://github.com/ansible/ansible/pull/57318

Danke, James. Da Leute zu diesem Problem kommen, um der Warnmeldung nachzugehen, füge ich Informationen hinzu, die meiner Meinung nach nützlich sein könnten:

Um die automatische Umwandlung von ≥2.10-Gruppennamen tragbarer/permanent zu deaktivieren, bis Sie möglicherweise bereit sind, ungültige Gruppen aus Ihrem Inventar zu entfernen, fügen Sie force_valid_group_names = never zum [defaults] INI-Abschnitt von . hinzu ansible.cfg .

Um alle Gruppen und ungültigen Zeichen zu sehen, die die Warnung auslösen (vielleicht, damit Sie sie für die Ausmusterung auswählen können), können Sie so etwas wie diese ansible CLI-No-Op tun:

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

Diese ungültigen Zeichen sind (Stand 04.06.2019) als Konstante INVALID_VARIABLE_NAMES in:
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
als '^[\d\W]|[^\w]' ,
das heißt: any leading non-alpha character OR any character other than alpha-numeric and underscore .
(Ich hoffe, ich habe das richtig verstanden)

Wenn Sie veraltete Warnungen als störend empfinden, können Sie sie auch für jeden ansible- Befehl oder den ansible Ad-hoc-Befehl dauerhaft deaktivieren, indem Sie deprecation_warnings = False zum selben [defaults] hinzufügen. ansible.cfg , aber ich würde davon abraten (da Sie möglicherweise wichtige Neuigkeiten verpassen) und stattdessen Inline-Shell-Umgebungsvariablen wie folgt verwenden:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

Die Inventaranalyse von [WARNING] s wird jedoch nicht verschwinden. Es gibt (noch?) keine spezifische Konfigurations- oder Umgebungsvariable, um alle Warnungen auszuschalten, aber wenn es Sie wirklich stört, können Sie einfach alle stderr an /dev/null senden (fügen Sie hier "Best Practice"-Vorbehalte ein):

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

Hoffe das hilft jemandem, irgendwo.

Ich finde nur veraltete Warnmeldungen ärgerlich, wenn sie keinen Migrationspfad bereitstellen. In Anbetracht der Tatsache, dass der Platz begrenzt ist und die Korrektur wahrscheinlich aktualisiert werden muss, würde ich es sehr nützlich finden, Links zu Tickets bereitzustellen, die Lösungen, Problemumgehungen usw. dokumentieren können.

Ein Ansatz wie dieser könnte zusätzliche Arbeit ersparen, die für die Verbesserung unvollständiger Warnmeldungen erforderlich ist, da wir die Meldung nicht aktualisieren und auf einige Versionen zurückportieren müssten.

PS. Das Deaktivieren von Warnungen zu veralteten Versionen würde ich niemandem empfehlen, vielleicht nur, wenn ein Projekt bereits vor seinem endgültigen Schicksal steht ;)

Ich begann, diese Warnung zu erhalten, fand jedoch keine Hinweise im Portierungshandbuch und keine Hinweise, wie oder was zu beheben ist.

Die meisten meiner Warnungen stammen von der ec2.py, wo die instance_id die - (zB: i-033f62b586143dff7 ) und die Regionen (zB: eu-central-1c ) verwendet, also haben wir keine echte Lösung für diese

Schließlich hat dies einige meiner Playbooks kaputt gemacht, wo ich when: ansible_hostname in groups['varnish'] und das ansible_hostname varnish-eu-central-1c-001 .
In der Vergangenheit hat das gut funktioniert, jetzt muss ich inventory_hostname , um varnish_eu_central_1c_001 bekommen und ein Match gegen die groups['varnish']

Dies erfordert also zumindest und dringend eine Warnung im Portierungsleitfaden, dass inventory_hostname und groups[] möglicherweise unterschiedliche Daten zurückgeben

Ich möchte eine Aussage über die Warnung wiederholen, die vom dynamischen EC2-Inventarskript generiert wird. Mir ist aufgefallen, dass es eine ec2.ini Konfigurationseinstellung gibt, um die Gruppierung von Hosts nach Instanz-ID ( group_by_instance_id = False ) zu deaktivieren, aber eine Einstellung, die die Warnung für mich nicht so auflöste, wie ich es erwartet hatte - ich habe sichergestellt, dass ich den lokalen Inventar-Cache geleert.

Gibt es spezielle Problemumgehungen für dynamisches EC2-Inventar?

Diese ungültigen Zeichen sind (Stand 04.06.2019) als Konstante INVALID_VARIABLE_NAMES in:
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
als '^[\d\W]|[^\w]' ,
das heißt: any leading non-alpha character OR any character other than alpha-numeric and underscore .
(Ich hoffe, ich habe das richtig verstanden)

Klingt für mich richtig. Sie sollten eine Docs-PR mit diesen Informationen einreichen.

Wenn Sie veraltete Warnungen als störend empfinden, können Sie sie auch für jeden ansible- Befehl oder den ansible Ad-hoc-Befehl dauerhaft deaktivieren, indem Sie deprecation_warnings = False zu demselben [defaults] hinzufügen. ansible.cfg , aber ich würde davon abraten (da Sie möglicherweise wichtige Neuigkeiten verpassen) und stattdessen Inline-Shell-Umgebungsvariablen wie diese verwenden:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

Die Inventaranalyse von [WARNING] s wird jedoch nicht verschwinden. Es gibt keine spezifische Konfigurations- oder Umgebungsvariable, um alle Warnungen auszuschalten (noch?), aber wenn es Sie wirklich stört, können Sie einfach alle stderr an /dev/null senden (fügen Sie hier "Best Practice"-Vorbehalte ein):

Die undokumentierte Option ignore bietet diese Funktionalität. Docs-PR hier: https://github.com/ansible/ansible/pull/57318

Ab 2.8.2 wird diese Veraltungswarnung aufgehoben, wenn Sie explizit eine der Optionen festlegen.

Wo diskutiert das ansible-Entwicklerteam diese Art von Entscheidungen? Es ist für uns Benutzer sehr schwer, die Gründe dafür zu verstehen. Wenn es sich um eine reine Argumentation im "Python-Stil" und nicht um eine praktische Argumentation handelt, könnte es sich lohnen, es noch einmal zu überdenken? Wenn ein Bindestrich in Gruppennamen in zukünftigen Versionen von ansible Probleme macht, könnte dies eher ein Problem mit der Implementierung sein als die Benennung einer Gruppe?

Für mich klingt das eher nach einer kosmetischen Veränderung, als nach etwas, das richtig durchdacht wurde.

Ein Gruppenname ist kein Variablenname, sondern der Inhalt eines solchen. Ein Bindestrich/Strich ist nur ein Zeichen, das auch eine äußerst beliebte Art ist, Informationen in einer Namenskonvention zu gruppieren. Gegenüber dem Ausrufezeichen oder dem Stern hat es in einer Grenzklausel keine besondere Bedeutung.

Die Kosten zur Abschwächung dieses Problems sind enorm, da Tausende von Websites nicht nur die Gruppennamen in den Inventaren ändern müssen, sondern auch alle ihre Playbooks und selbst entwickelten Rollen durchgehen und sie alle erneut testen müssen.

Wenn es für "Bauern" überhaupt eine Möglichkeit gibt, sich Gehör zu verschaffen, würde ich gerne meine Meinung teilen und versuchen zu verstehen, wie diese Idee entstanden ist.

Ich habe verstanden, dass die Änderung an ansible vorgenommen wurde, weil Benutzer Fehler gemacht haben, z. B. beim Versuch, groups.group-name anstelle von groups['group-name'] . AIUI, es ist eine Änderung, die ausschließlich dazu dient, Supportprobleme zu reduzieren. (Ich persönlich bin gegen die Änderung.)

Das alte Verhalten wird nicht verschwinden; es wird einfach nicht mehr verfügbar sein, ohne das alte Verhalten explizit auszuwählen.

Traurig zu hören.

Mein Anwendungsfall ist, dass ich den Befehl "ansible-inventory" so in eine Vagrant-Datei einbette, dass es unhöflich ist, Dinge in die ansible.cfg zu schreiben, und dass es hilfreich wäre, in der Lage zu sein, die Verhalten als Befehlszeilenoption (nicht Umgebungsvariable).

Normalerweise sind solche Änderungen auf gute Absichten zurückzuführen, führen jedoch möglicherweise nicht immer zu dem gewünschten Ergebnis.

Mein Problem mit dieser Änderung ist, dass Gruppennamen jetzt etwas "besonders" werden - Bindestriche sind in Hostnamen erlaubt, aber nicht in Gruppennamen, was es etwas seltsam macht, wenn man am Anfang eines Playbooks im Abschnitt hosts: denkt Ich könnte Host- und/oder Gruppennamen schreiben.

Ist die Erklärung von @sivel wirklich der einzige Grund für diese Änderung? Was ist dann mit hosvars['foo-host'] ? Ich hoffe, niemand denkt daran, Bindestriche auch in Inventar-Hostnamen ungültig zu machen ...
Außer hostvars gibt es eine Menge anderer Beispiele, bei denen die "Punktnotation" nicht verwendet werden kann, so dass Sie wissen müssen, wann welche Form verwendet werden soll. Ich finde es ziemlich willkürlich, Gruppennamen herauszugreifen.

Obwohl das Argument mit der Punktnotation eine einigermaßen gültige Entschuldigung ist, sehe ich dies nicht, um Ihre Supportprobleme zu beheben, ohne stattdessen die Dokumentation zu verbessern. Wenn Ihre Benutzer etwas Dummes tun, ist Ihre Dokumentation nicht ausreichend. Alles, was den Entwicklern gelungen ist, ist, viele Benutzer zu entfremden. Gruppennamen sehe ich als willkürliche Zeichenfolgenwerte. Die Beschränkung auf alphanumerische Zeichen und Unterstriche ist ehrlich gesagt etwas mühsam, besonders wenn RFCs für Hostnamen Bindestriche, Punkte usw. zulassen. Bindestriche werden häufig für Deskriptor-Strings verwendet. Wenn Sie Ihr Supportvolumen reduzieren möchten, versuchen Sie, das Problem mit der Punktnotation aus einer anderen Richtung zu lösen. Erstellen Sie ein Validierungsskript, das Ihre Supportteams bereitstellen können, das auf Best-Practice-Probleme überprüft und als Beispiel Warnungen oder Anleitungen enthält. Aktualisieren Sie Ihre Dokumentation bezüglich des Vorbehalts der Punktnotation, sodass sie groß, fett, rot, blinkend usw. ist. Solche Supportfälle sind am Ende 1-minütige Anrufe, wenn Ihre Dokumentation das Problem bereits behandelt. Ans Telefon gehen, Problem sehen, Dokumentlink angeben, fertig.

Bindestriche in Gruppennamen sind sowohl gültige INI als auch gültiges YAML. Ich verstehe nicht, warum ich als Benutzer alle meine Gruppen umbenennen muss, nur weil die Namen nicht als Python-Variablennamen verwendet werden können?

Außerdem hinterfragt man die Gründe für diese Entscheidung, - in Gruppennamen zu verwerfen. Es war schon ärgerlich genug, keine Bindestriche im dynamischen Inventar keyed_groups , aber alle unsere Gruppen in unseren Inventardateien und ansible-playbook -l ... Befehlen umbenennen zu müssen, nur um hypothetische Syntaxprobleme zu vermeiden, ist wird schmerzhaft.

FWIW haben wir eine Konvention für die Benennung von Rollengruppen wie foo_server und Hostgruppen wie foo-dev oder foo-test . Fast 100 % unserer Ansible-Nutzung sind Befehle wie ansible-playbook -l foo-dev , daher wird diese Änderung viel Aufwand erfordern, um das Muskelgedächtnis zu bekämpfen.

Ich bin mir nicht sicher, ob das Hinzufügen eines weiteren

Bitte unterstützen Sie Bindestriche zusammen mit Buchstaben, Zahlen und Unterstrichen in Gruppennamen (aber ich habe auch nichts gegen Punkte)!

Wir verwenden häufig Bindestriche in Gruppennamen. Beides zum Gruppieren von Namen wie folgt:

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

und das Inventar zu _missbrauchen_, um die Hostliste an einem Ort zu halten (anstatt die Hostnamen in verschiedenen var-Dateien zu verwalten), wie folgt:

[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 %}
{% für Host in _hostlist %}
...
```

Wir verwenden Punkte nicht nur, um Unterschiede zwischen Gruppen- und Hostnamen sichtbar zu machen.

Das Wort UNGÜLTIG in TRANSFORM_INVALID_GROUP_CHARS gibt keine Zuversicht, dass es möglich ist, sie auf lange Sicht weiter zu verwenden.

Wenn Sie die Verwendung dieser Zeichen vermeiden möchten, nennen Sie sie besser _UNSICHER_ Zeichen, zeigen Sie eine Warnung an und lassen Sie die Benutzer entscheiden, ob sie diese Warnung sehen oder nicht. Aber verbieten oder ersetzen Sie diese Zeichen niemals!

Benutzer sollten a) diese Warnung stummschalten (mit Schlüsselwörtern wie ALLOW_UNSAFE_GROUP_CHARS), b) ihre Gruppennamen ändern (wenn möglich) oder c) einfach mit dieser Warnung leben. Die meisten werden sich sowieso zwischen den ersten beiden Optionen entscheiden.

Ich halte dies auch für sinnlos, da ein Bindestrich "-" ein Standardtrennzeichen ist, das in fast jeder Art von computerbezogenen Werkzeugen verwendet wird, und der Versuch, sich einer "Religion" anzupassen, scheint einengend zu sein!!!

Das alte Verhalten wird nicht verschwinden; es wird einfach nicht mehr verfügbar sein, ohne das alte Verhalten explizit auszuwählen.

Ich wäre nicht so besorgt über diese Einstellung, wenn es tatsächlich möglich wäre, Bindestriche in Gruppennamen zu aktivieren. Dann könnte es aus der Perspektive eines neuen Benutzers verständlich sein.

Die Veraltungswarnung impliziert jedoch, dass die Option TRANSFORM_INVALID_GROUP_CHARS=never in Ansible 2.10 wegfällt und wir daher alle unsere Gruppen umbenennen müssen, bevor Ansible 2.10 veröffentlicht wird?

[ABLAUFWARNUNG]: Die Einstellungen für TRANSFORM_INVALID_GROUP_CHARS sind standardmäßig so eingestellt, dass ungültige Zeichen in Gruppennamen zugelassen werden. Diese Funktion wird in Version 2.10 entfernt. Veraltete Warnungen können deaktiviert werden, indem deprecation_warnings=False in ansible.cfg gesetzt wird.

Außerdem erzwingt die Verwendung des dynamischen Inventar-Plugins keyed_groups die Transformation von Gruppennamen, auch wenn TRANSFORM_INVALID_GROUP_CHARS=never gesetzt ist: 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

Gewünschtes Verhalten

• Die Verwendung von TRANSFORM_INVALID_GROUP_CHARS=never muss auch in Zukunft unterstützt werden

  BEARBEITEN: Beim Lesen des Codes klingt es so, als ob TRANSFORM_INVALID_GROUP_CHARS beibehalten, aber in 2.10 die Standardeinstellung auf always geändert werden soll - in diesem Fall ist die Veraltungswarnung nicht sehr gut formuliert: https:/ /github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/inventory/group.py#L50

• Die Verwendung von TRANSFORM_INVALID_GROUP_CHARS=never sollte die Einstellungswarnung stummschalten

  Dies scheint bereits mit der undokumentierten Option ignore möglich zu sein: https://github.com/ansible/ansible/pull/57318

• Die Verwendung von TRANSFORM_INVALID_GROUP_CHARS=never sollte auch die Verwendung von Bindestrichen in dynamischem Inventar ermöglichen keyed_groups

  BEARBEITEN: Dies ist eindeutig für die Abwärtskompatibilität für Ansible 2.7, die die generierten Gruppennamen bedingungslos transformiert. Ein explizites Opt-Out hierfür wäre schön.

In Bezug auf Variablennamen verstehe ich nicht, warum das Format des Wörterbuchschlüssels mit der Syntax des Variablennamens gleichgesetzt werden sollte? AFAIK hat keine Programmiersprache eine solche Einschränkung. In Python können Sie so ziemlich jeden String als Wörterbuchschlüssel verwenden.

Ist "groups" keine Variable vom Typ Wörterbuch und sowohl Host- als auch Gruppennamen sind nur einfache Wörterbuchschlüssel in Ansible. Sie sind selbst keine Eigenschaften oder Variablen, oder doch?

Ich würde die Syntax von groups.foo-group lieber verbieten als von groups["foo-group"]. Wenn g = "foo-group", verwenden Sie dann groups.g oder groups[g]?

Die Verwendung von ansible.cfg [default] force_valid_group_names = ignore oder export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore scheint unter Ansible 2.8.1 nicht zu funktionieren. Es gibt immer noch die Veraltungswarnung.

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

Liegt das daran, dass es noch nicht im gültigen choices ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Die Verwendung von ansible.cfg [default] force_valid_group_names = ignore oder export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore scheint unter Ansible 2.8.1 nicht zu funktionieren. Es gibt immer noch die Veraltungswarnung.

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

Liegt das daran, dass es noch nicht im gültigen choices ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Dies ist ein Fehler, der in der kommenden Version 2.8.2 behoben wurde. Sie können export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore und es werden alle Warnungen gelöscht.

(Die Ignorieren-Option ist immer noch nicht dokumentiert: https://github.com/ansible/ansible/pull/57318 )

Das wird alle kaputt machen. Schlechte Entscheidung.

Gibt es eine Möglichkeit, mit den Betreuern darüber zu diskutieren?

Vielleicht könnte einer der Betreuer hier ein wenig näher erläutern, ob es sich nur um ein Support-Problem handelt oder ob sie Python-Konstrukte verwenden, die wirklich kaputt gehen?

Ich möchte nur hinzufügen, dass dies ziemlich nervig ist und die Unfähigkeit, das Problem wirklich herauszufinden, war auch ärgerlich, ich musste buchstäblich ansible-playbook "insert yaml file here" > output.txt tun, um das Problem herauszufinden.

Stimme den meisten Postern hier zu. Das Entfernen von Bindestrichen aus Gruppennamen scheint eine schlecht durchdachte Entscheidung zu sein, oder eine, die von der Implementierung und nicht von der Semantik angetrieben wird.

Diese Änderung macht für mich absolut keinen Sinn. Ansible-Entwickler möchten Tausende und Abertausende von Benutzern zwingen, ihre Gruppenbenennung zu ändern, nur weil sie eine zusätzliche Syntax (keine fehlende) für den Zugriff auf Gruppen wünschen? Ist das ein Scherz?

Wir verwenden Striche und Punkte in großen Setups.
Unser Muster ist product-name.environment.datacenter und es macht die Dinge sehr klar.
Ich kann mir nicht vorstellen, - und . da dies das Inventar völlig unlesbar machen würde.

Wir verwenden ansible Inventar-Plugins, die die lokale CMDB nach Gruppennamen abfragen, die Bindestriche enthalten (und weiterhin enthalten werden). Es würde vieles kaputt machen, wenn dies in Zukunft ungültig wäre.

Wir verwenden Striche und Punkte in großen Setups.
Unser Muster ist product-name.environment.datacenter und es macht die Dinge sehr klar.
Ich kann mir nicht vorstellen, - und . da dies das Inventar völlig unlesbar machen würde.

Wir verwenden einen ähnlichen Ansatz mit einem hierarchischen Namensschema (inspiriert von Java, zB org.company.product-name.component).
Es wäre ein absoluter Horror, auf Unterstriche zurückgreifen zu müssen.

hä. wir standen auch vor diesem Problem. Wir verwenden Bindestrich in unseren Gruppennamen intensiv.
Wenn jemand erklären könnte, welches Problem auf die Verwendung von Bindestrichen in einem Diktat zurückzuführen ist, würde ich mich freuen, es zu wissen

Ich wiederhole hauptsächlich, was andere gesagt haben, aber ich wollte etwas Input hinzufügen. Ich denke, wenn diese Änderung implementiert wird, sollte das Flag zum Erlauben von Bindestrichen beibehalten und beibehalten werden. Obwohl ich verstehe, dass Python Unterstriche erwartet, werden Bindestriche häufig für Hostnamen und Hostgruppennamen verwendet. In unserer Umgebung generieren wir das Inventar dynamisch aus Hosts und Hostgruppen in unserem LDAP/Kerberos-Verzeichnis. Ich erwähne dies, weil es uns zwar möglich wäre, die Host- und Gruppennamen zu ändern, dies jedoch nicht vorzuziehen ist.

Was müssen wir tun, um diese Funktion zu deaktivieren? Unsere lokalen Ansible-Bereitstellungsskripts sind übersät mit Gruppennamen mit Bindestrichen. Wir verwenden sie natürlich nicht mit Punktnotation. Aber sie alle zu ändern, wäre eine wahrhaft monumentale Aufgabe. Ich würde es vorziehen, mich abzumelden und gleichzeitig mein Team zu ermutigen, in Zukunft keine Bindestriche mehr zu verwenden und Bindestriche nach Möglichkeit in Unterstriche umzuwandeln, obwohl dieser letzte Teil nicht immer so einfach ist, wie es scheint.

Setzt man also einfach force_valid_group_names = false in ansible.cfg ? Das scheint richtig zu sein basierend auf d241794#diff-fd24ad93fbc32f454761746c1ac908f2

Testen Sie Ansible 2.8.2, diese INI-Einstellung funktioniert meiner Meinung nach nicht wie erwartet, dies wird nur die DEPRECATION WARNING entfernen, während ich möchte, dass Ansible meine Gruppen mit Bindestrichen verwendet, ohne sich zu beschweren.

Hier die Ergebnisse ohne :

[ABLAUFWARNUNG]: Die Einstellungen für TRANSFORM_INVALID_GROUP_CHARS sind standardmäßig so eingestellt, dass ungültige Zeichen in Gruppennamen zugelassen werden. Diese Funktion wird in Version 2.10 entfernt. Missbilligung
Warnungen können durch Setzen von deprecation_warnings=False in ansible.cfg deaktiviert werden.
[WARNUNG]: Ungültige Zeichen wurden in Gruppennamen gefunden, aber nicht ersetzt. Verwenden Sie -vvvv, um Details anzuzeigen

Und mit der Einstellung "false" in ansible.cfg:

[WARNUNG]: Ungültige Zeichen wurden in Gruppennamen gefunden und automatisch ersetzt. Verwenden Sie -vvvv, um Details anzuzeigen

Die Verwendung von ansible.cfg [default] force_valid_group_names = ignore oder export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore scheint unter Ansible 2.8.1 nicht zu funktionieren. Es gibt immer noch die Veraltungswarnung.

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

Liegt das daran, dass es noch nicht im gültigen choices ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Dies ist ein Fehler, der in der kommenden Version 2.8.2 behoben wurde. Sie können export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore und es werden alle Warnungen gelöscht.

(Die Ignorieren-Option ist noch nicht dokumentiert: #57318 )

Aber werden nur Warnungen unterdrückt oder können wir dadurch weiterhin Bindestriche in Gruppen verwenden?
Dies ist nicht ganz klar.

Ich stimme allen Kritikern hier zu.

Dies trägt nicht nur dazu bei, Playbooks zu zerstören, sondern trägt auch zu dem bei, was ich das Konventionschaos nenne. Jetzt haben Hostnamen und Gruppennamen eine andere Konvention, nur weil einige isolierte Anfänger über das Problem mit dem Bindestrich in Punktnotation stolpern? Erraten Sie, was ? Sie werden immer noch darüber stolpern, und das Feature wird es geschafft haben, die Leute zu verärgern und kein Problem zu lösen. Bravo.

Ansible Gruppennamen sollten in der Lage sein, die Benennung der realen Weltgruppen, die sie repräsentieren, zu respektieren.

Wenn alle anderen Tools eine Reihe von Hosts my-backend-service aufrufen, warum sollte Ansible die Operatoren zwingen, dies in my_backend_service zu übersetzen, um die Benennungsregeln von Python zu erfüllen.

Es ist heute ein wirklich trauriger Tag. Als mir ein JR-Mitarbeiter diese Abwertung vorbrachte, dachte ich, dass das Ansible-Team auf keinen Fall so realitätsfern sein würde, um eine so egoistische Entscheidung zu treffen. Ich liebe Ansible absolut für das, was es erreichen kann (aus einer Benutzerperspektive, die NULL damit zu tun hat, dass es in Python geschrieben ist). rationale Entscheidungen. Ich hoffe, IBM bringt das in Ordnung..
ODER
Vielleicht gibt es ein neues glänzendes GO-Äquivalent, zu dem wir wechseln können.

Da dieses Verhalten offensichtlich sehr umstritten ist, frage ich mich, ob dies beschlossene Sache ist und auf jeden Fall umgesetzt wird?

Ich würde mich sehr über eine Antwort von den Leuten hinter dieser Entscheidung freuen und hoffe auf eine Ausarbeitung über "dies ist eine Python-Standardsache".

Da dieses Verhalten offensichtlich sehr umstritten ist, frage ich mich, ob dies beschlossene Sache ist und auf jeden Fall umgesetzt wird?

Ich würde mich sehr über eine Antwort von den Leuten hinter dieser Entscheidung freuen und hoffe auf eine Ausarbeitung über "dies ist eine Python-Standardsache".

Ich stimme mit Ihnen ein. Erst kürzlich wurde das "go" -Projekt von einem unpopulären Vorschlag abgelöst (siehe https://github.com/golang/go/issues/32437#issuecomment-512035919), so dass solche Dinge (und manchmal sollten) noch einmal überdacht werden können und schließlich auch zurückgetreten.

Es ist auch ein interessantes Thema und Diskussionen, vielleicht nicht nur für diese Funktionsänderung. Es ist schwer herauszufinden, wie die Governance von Ansible als Produkt funktioniert. Vielleicht sollte _jemand_ etwas zu https://www.ansible.com/ansiblefest mitbringen?

Da sich viele von uns am Kopf kratzen und nicht verstehen, wie ein String/Variableninhalt/Gruppenname in irgendeiner Weise Probleme mit Python-Codierungsstilen aufwerfen kann, wäre es schön, hier eine Antwort von den Betreuern zu erhalten, die argumentieren, warum dies so auffallen würde ein Problem.

Ich kann verstehen, wenn sie einen Codierungsstil für Variablennamen und -strukturen beibehalten möchten, aber den Inhalt eines Arrays oder einer Variablen?

Hier ist eine kurze Diskussion über die Punktnotation von Diktaten. Es ist möglich, aber hässlich. https://stackoverflow.com/questions/16279212/how-to-use-dot-notation-for-dict-in-python

Die Tatsache, dass es diesbezüglich Supportprobleme gibt, ist meiner Meinung nach ein Dokumentationsproblem und kein Funktionsproblem. Wenn überhaupt, würde ich argumentieren, dass Gruppennamen KEINE Variablen sein sollten.

Ebenso wie die Tatsache, dass diese Änderung implementiert wurde, bevor eine Dokumentation verfügbar war/ist.

Welche Auswirkungen hat diese Änderung? Muss ich alle meine Ansible-Inventare sorgfältig bearbeiten, um sicherzustellen, dass die Gruppennamen keine Bindestriche enthalten?

@CMoH IMO ist die beste Moment , force_valid_group_names = ignore zu Ihrer Konfiguration hinzuzufügen und ansible 2.8.2 oder höher auszuführen.

@skyscooby , selbst das ist eine PITA. Die Sache, dass es nicht möglich ist, diese Zeile als Standard in /etc/ansible.cfg und lokale ansible.cfg in Playbook-Verzeichnissen für andere Konfigurationen zu verwenden. Das bedeutet, dass alle existierenden ansible.cfg Dateien geändert werden müssen.

Oder gibt es eine Möglichkeit, globale Standardeinstellungen einzurichten (ohne der Benutzerumgebung eine weitere Variable hinzuzufügen)?

@Cougar stimmte zu, dass diese Wahl von Ansible eine PITA ist.

Ihr Problem ist jedoch nicht nur auf diese Einstellung zurückzuführen. Wir hatten ähnliche Probleme und raten jetzt von der Verwendung von ansible.cfg-Dateien pro Projekt ab, da die meisten Einstellungen mit Umgebungsvariablen festgelegt werden können, die die Einstellungen der cfg-Datei überschreiben aus irgendeinem obskuren Grund eine bestimmte Einstellung erforderlich ist. Wir bitten sie, die ENV-Methode zu verwenden, die den Rest der Einstellungen, die sie nicht ändern müssen, auf Unternehmensstandards belässt. Wir bauen einen Basis-Docker-Container mit dieser Standardkonfiguration und einzelne Projekte fügen einfach ENV-Einträge in ihr eigenes Dockerfile hinzu, während sie ihr Image des Basis-Ansible-Containers aufbauen. Alle Ansible werden innerhalb des Containers ausgeführt, so dass wir sicher sind, dass alle Pip-Module, Ansible-Versionen und Laufzeittools durchgehend identisch sind.

BEARBEITEN: Dies gibt uns auch die Möglichkeit, neue Versionen von Ansible einzuführen und Probleme wie dieses zu kontrollieren, bevor alle im Unternehmen davon betroffen sind :)

Ich habe etwas gegraben.

Diese Funktionalität wurde ursprünglich in PR https://github.com/ansible/ansible/pull/52748 hinzugefügt, angeblich um die Funktionsanforderung https://github.com/ansible/ansible/issues/40581 zu unterstützen

eine Beschreibung des Ziels: https://github.com/ansible/ansible/pull/52748#issuecomment -467976473

erste Version DIESES Symptoms (wenn auch andere Ursache): https://github.com/ansible/ansible/issues/51844

Mann, ich habe #52748 jetzt schon so oft gelesen.

Nach meinem Verständnis wurden Gruppennamen zuvor in den Plugins und im Kern bereinigt, und jemand (aus welchen Gründen auch immer, da mir immer noch nicht klar ist, warum) entschied, dass Gruppennamen den Namenskonventionen für Python-Variablen folgen sollten.

Also hat #52748 stattdessen die sanitären Einrichtungen ins Inventar geschoben, was für so viele Leute kaputt geht. Vor allem Leute, die clevere Namenskonventionen verwenden, zum Beispiel in AWS, Azure usw., um Hosts Gruppen zuzuordnen.

Wenn wir den gleichen Standard/die gleiche Namenskonvention für Hostnamen verwenden würden, würden wir sicherlich an Schwung verlieren und Benutzer verlieren.

Ein Gruppenname ist ein Name, keine Variable. Die Verwendung von Bindestrichen in Gruppennamen (genau wie in Hostnamen) ist sinnvoll. Die Übersetzung (Sanierung) sollte nicht auf Inventarebene (von uns, den Benutzern) erfolgen müssen und im besten Fall auch nie.

Ich sehe wirklich keinen Vorteil darin, dies durchzusetzen. Die Diskussion scheint auch "." und ":", die manche Leute gerne in Gruppennamen verwenden. Persönlich nutze ich sie nicht, sehe aber auch keinen Schaden darin.

Solange Cloud-Anbieter Bindestriche in ihren Metainformationen verwenden, sollten wir sie für die Gruppierung verwenden können. Eigentlich sollte das nicht einmal der Treiber sein. Wenn ich eine Gruppe abcde benennen möchte, sollte das eigentlich kein Problem sein. Es ist ein sehr nützliches Trennzeichen.

Dieser Thread scheint jedoch keine Aufmerksamkeit von Entwicklern oder Betreuern auf sich zu ziehen. Ich glaube, wir sprechen vor tauben Ohren.

Entwickler/Betreuer: Bitte, bitte, bitte erlaubt Bindestriche in Gruppennamen!

Um einige Missverständnisse zu klären, die zum Teil auf meine Fehler zurückzuführen waren und die ersten Nachrichten unklar gemacht haben, die neuesten Versionen haben Korrekturen für einige der Probleme, die hier immer wieder angesprochen werden, andere Korrekturen sind noch in Arbeit:

Um es nur einmal klar zu sagen, SIE WERDEN IMMER IN GRUPPENNAMEN Striche verwenden können, auch Punkte und andere Zeichen, die jetzt als "ungültig" gelten, nur nicht standardmäßig. Diese 'Standardeinstellung' ist veraltet, die Standardeinstellung ist in 2.11 'sicher', aber Sie haben immer die Möglichkeit, sich für das alte Verhalten zu entscheiden.

Und um zu erklären, wie und warum wir hierher gekommen sind:

Erstens wurden die Gruppennamen IMMER bereinigt, sie hatten nur unterschiedliche inkonsistente Regeln, je nach verwendetem Inventartyp, Skripte waren überall, YAML- und INI-Formate machten jeweils ihr eigenes Ding. Die wichtigste Änderung war die „Zentralisierung und Normalisierung der Sanitärversorgung“, die bereits in 2.4 beschlossen, aber erst am 2.8 vollständig umgesetzt wurde. Die Absicht war, eine Norm oder Baseline bereitzustellen, die alle in Ansilbe sicher verwenden können. Wir wissen jedoch, dass viele Leute "unsichere" oder "ungültige" Zeichen für Variablen verwenden, daher haben wir dies nicht nur global, sondern auch von einigen der Inventar-Plugins.

Die anfängliche Implementierung hatte einige Probleme und viele Diskussionen (nein, wir entscheiden das nicht im Verborgenen, wir haben öffentliche Treffen im IRC, zu denen Sie alle willkommen sind, https://github.com/ansible/community/blob/master /meetings/README.md) und ein Großteil des Feedbacks wurde aufgenommen (diese werden auch protokolliert, damit Sie die Diskussionen und Argumente sehen können. . Nachdem wir in 2.8 herausgekommen sind, haben wir eine weitere Runde Feedback bekommen und wir haben einige Fehler behoben, wie zum Beispiel immer eine Deprecation, nicht nur bei der Verwendung der Standardeinstellung und insbesondere beim Wortlaut der Dokumentation und der Warnungen.

• 'Warum Python-Namen?'
  Vor allem, weil Ansible Python und JInja verwendet (das auch Python verwendet) und einige Verwendungen von Gruppen (meistens in unseren frühen Beispielen, aber auch viele von Drittanbietern) können Fehler in Playbooks verursachen, dh stuff: '{{ groups.gropup-name-with-dash ... }}' oder schlimmer ein group.name.with.dots . Dies führt zu Verwirrung bei vielen Benutzern, die die Jinja-Funktion der 'Punktnotation für den Variablenzugriff' verwenden möchten, und deshalb sollte die Standardeinstellung für alle Benutzer sicher sein. Die meisten Leute in diesem Beitrag mögen dem nicht zustimmen, aber dies ist für viele Leute ein echtes Problem und sollte keine "Falle" sein, die auf neue oder alte Ansible-Benutzer wartet. Diejenigen, die sich abmelden, sind dann dafür verantwortlich, die Nutzungsunterbrechung in anderen Teilen von Ansible zu vermeiden.

• "Was wäre, wenn mir gefallen würde, dass jedes Inventar unterschiedliche sanitäre Einrichtungen hat?"
  Nun, Sie können die "zentrale" Hygiene immer noch deaktivieren und diejenige für Ihre spezifische Inventarquelle aktivieren. Bei den beliebtesten neuen Inventar-Plugins, die die alten Skripte ersetzen, wurden Optionen hinzugefügt, um das Skriptverhalten zu emulieren, im schlimmsten Fall können Sie immer noch verwenden die Inventarskripte.

• 'Warum nicht Hostnamen/sind Hostnamen als nächstes?'
  Wie bei Gruppen gab es schon immer eine Sanatisierung von Hostnamen, die sich jedoch nicht geändert hat. Hostnamen haben andere Anforderungen, z. B. DNS-auflösbar
  für Netzwerkverbindungen oder einen gültigen Pfad für Chroot-Verbindungen. Glücklicherweise gibt es auch wenige bis gar keine Beispiele für die Verwendung von Hostnamen in Punktnotation, dies war keine gängige Praxis und würde zu einem Problem werden, wenn die Leute plötzlich anfangen würden, sie zu verwenden, aber im Gegensatz zu Gruppennamen haben wir dies bisher vermieden. Wenn es in Zukunft zu einem Problem wird ... sehe ich auch keine gute Lösung.

Beachten Sie, dass dieses spezielle Ticket (nicht gut genug Beschreibung / Informationen) etwas ist, das ich bereits anspreche, und hoffe, dass es bald behoben wird. Was den Rest der Diskussion betrifft, die Entwickler verwenden Github nicht als Forum, einige Tickets gehen darauf über, das vorherige Ticket, das geschlossen ist und auch einen langen Thread hat, wurde bis vor kurzem ignoriert, hauptsächlich weil die Entwickler geschlossene Probleme herausfiltern und erwarten Diskussionen im IRC, die Mailingliste oder neue Ausgaben.

Ich hoffe, dass dies alle wichtigen Probleme anspricht, wie immer sind wir offen für Diskussionen, zögern Sie nicht, ML oder IRC zu besuchen, wir vermeiden es einfach, Github zu verwenden, da es für solche Dinge kein guter Ort ist.

Vielen Dank für die Aufklärung.

Vielen Dank, dass Sie sich die Zeit genommen haben, dies zu erklären, obwohl es viel einfacher gewesen wäre, die Unterstützung der Punktnotation einzustellen und diese Unterstützung für einige Releases einzustellen. Das verwenden weniger Leute im Vergleich zu den Leuten, die ungültige Zeichen in ihren Gruppennamen haben. Se la vie

@skyscooby das Problem ist, dass es nicht Ansible ist, es ist Jinja.

Um es nur einmal klar zu sagen, SIE WERDEN IMMER IN GRUPPENNAMEN Striche verwenden können, auch Punkte und andere Zeichen, die jetzt als "ungültig" gelten, nur nicht standardmäßig.

Okay, das ist gut zu wissen, danke für die Aufklärung. Die Benutzerfreundlichkeit muss jedoch wirklich verbessert werden. Sie haben den "Fluch des Wissens". Versuchen Sie sich einfach in die Lage eines Benutzers zu versetzen, der das sieht:

[ABLAUFWARNUNG]: Die Einstellungen für TRANSFORM_INVALID_GROUP_CHARS sind standardmäßig so eingestellt, dass ungültige Zeichen in Gruppennamen zugelassen werden
Benutzerkonfigurierbar bei Einstellung. Diese Funktion wird in Version 2.10 entfernt. Veraltete Warnungen können deaktiviert werden, indem deprecation_warnings=False in ansible.cfg gesetzt wird.
[WARNUNG]: Ungültige Zeichen wurden in Gruppennamen gefunden, aber nicht ersetzt. Verwenden Sie -vvvv, um Details anzuzeigen

Das ist ein langer, langer Weg von

[ABLAUFWARNUNG] Der Gruppenname 'my-servers' enthält '-', was ab Ansible 2.11 standardmäßig ungültig wird. Setzen Sie force_valid_group_names in ansible.cfg oder die Umgebungsvariable ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS auf "ignore", um dies zu unterdrücken. Weitere Informationen finden Sie unter https://docs.ansible.com/something .

... was ich als User unbedingt sehen wollte. Das hätte mir über eine Stunde erspart. Jetzt multiplizieren Sie das mit der Anzahl der Personen, die dieses Problem haben oder haben werden.

Wenn Bindestriche und Punkte in Gruppennamen ungültig sind, ist dies keine sinnvolle Vorgabe. Die Leute werden sie immer in ihren Gruppennamen haben. Von ihnen zu verlangen, dass sie noch eine weitere Variable in einer Konfigurationsdatei setzen, um ein vernünftiges Verhalten zu ermöglichen, ist IMHO nicht zu rechtfertigen.

Danke @bcoca für deinen Kommentar oben. Es wird sehr geschätzt.

Obwohl ich mit der Entscheidung nicht zufrieden bin, verstehe ich, dass eine Diskussion stattgefunden hat und eine Entscheidung getroffen wurde. Wenn die Entscheidung noch zur Debatte steht, sollte sie in der Mailingliste oder im IRC fortgeführt werden, darf dieses Thema jedoch nicht erfassen.

Zum Thema dieser Ausgabe möchte ich die folgenden Informationen in der offiziellen Dokumentation und den Portierungsleitfäden finden, um über diese Änderung informiert zu sein.

• Welche Gruppennamen sind standardmäßig gültig?
• Was ist zu tun, um weiterhin Gruppennamen einschließlich Bindestriche, Bindestriche, Punkte und Doppelpunkte zu verwenden?

Weil wir in all unseren Gruppen- und Hostnamen Bindestriche verwenden und daran nichts ändern werden. Also muss ich mich jedes Mal anmelden und mein ansible.cfg ändern, wenn ich eine neue Installation/Umgebung einrichte. Das ist schade für mich, aber irgendwie muss ich damit klarkommen. Das Mindeste, was ich erwarten würde, ist, dass dies entsprechend dokumentiert ist.

Um die Diskussion fortzusetzen, ob diese Änderung sinnvoll ist oder nicht, habe ich einen Thread in der Ansible Development-Gruppe eröffnet.

Mit freundlichen Grüßen,
Tronde

Ich möchte allen Mitwirkenden zu diesem Thema danken. Basierend auf dem, was ich hier gelesen habe, habe ich beschlossen, einen Blogbeitrag zu schreiben https://docs.sbarnea.com/ansible/naming-hosts-and-groups -- Hoffentlich würde er zusammenfassen, was Benutzer tun müssen.

@loop-evgeny Ich stimme zu, dass wir als Kernteam den "Fluch des Wissens" haben und es uns daran hindert, Dokumente und Fehler zu erstellen, die für alle nützlich sind. Wir verlassen uns auch vollständig auf die Community, die uns bei der Gestaltung von Ansible unterstützt und es für so viele Benutzer wie möglich einfach hält Pull-Anfrage. Die Nachricht, auf die Sie hinweisen, wird in der folgenden Datei gespeichert und wir würden es sehr begrüßen, wenn Sie uns eine PN mit der vorgeschlagenen Änderung senden könnten ...

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

@jctanner Normalerweise würde ich gerne eine PR einreichen, um ein kostenloses und nützliches Programm zu verbessern, das ich verwende. Die allgemeine Einstellung der Ansible-Entwickler zur Benutzerfreundlichkeit, ihr Eifer, Probleme, die ich für selbstverständliche Fehler (auch Designfehler) halte, als "funktionsgemäß" zu schließen, und die Tatsache, dass Ansible derzeit 2025 hat (das sind zweitausend !) Offene PRs geben mir wenig Zuversicht, dass meine Arbeit nicht umsonst ist. Wenn man sich wirklich "auf die Gemeinschaft verlassen" will, wie du sagst, dann ist IMHO ein substanzieller Kulturwandel nötig.

Hmm.. Diese Chance hat mich auch getroffen.

Leider verwenden wir Netzwerknamen als Gruppennamen und das ist nicht leicht zu ändern. Ich würde mich gerne für den Punktsyntax-Zucker für Gruppennamen entscheiden, da ich ihn nie verwendet habe (obwohl ich ihn mit anderen Variablen verwende).

Es wäre vorzuziehen, in Zukunft ansible-playbook whatever.yaml -l some.network.to.use zu verwenden. Die Verwendung eines anderen als das Netzwerk als Gruppennamen würde den Anwendungsfall massiv reduzieren.

Hi,
Ich bin im Moment etwas verwirrt. Könnte mir bitte jemand sagen, was ich in ansible.cfg einstellen muss, um in Zukunft ungültige Zeichen in Gruppennamen zuzulassen?

force_valid_group_names = ignore

Was ist die zukünftige Version von Ansible Regrading zu diesen Problemen? Wird Ansible irgendwann alle Bindestriche im Gruppennamen ablehnen, ohne dass force_valid_group_names ? (ohne Feedback von Benutzern zu hören, die von der Änderung betroffen waren und bei denen die Probleme noch nie aufgetreten sind, indem Bindestriche in Gruppennamen verwendet wurden)

Sorry Lies einfach die Kommentare von

Hi,
Ich sehe dieselbe Warnung, aber ich verstehe nicht, was ich ändern soll und ob wir es ändern sollen.
Hat das was mit Python zu tun?
Wie lösen?

Wenn ich mit force_valid_group_names = ignorieren ignoriere, wäre es damit notwendig, und wenn ich auf Ansible >= 2.10 upgrade?

Grüße,
Cesar Jorge

Wenn ich das richtig verstehe. Das einzige, was veraltet ist, ist die automatische Umwandlung von Gruppennamen. Das bedeutet, dass es völlig in Ordnung sein sollte, force_valid_group_names = ignore nach 2.10 und darüber hinaus zu setzen.

Es sollte auch völlig in Ordnung sein, weiterhin Bindestriche und alles, was Sie wollen, in Gruppennamen zu verwenden. Was Ansible in Zukunft nicht tun wird, ist, sie zu sanieren, damit Sie die punktierte Notation auch für "ungültige" Gruppennamen verwenden können. Zum Beispiel:

Ihr Inventar enthält eine Gruppe namens foo-bar.xyz . Jetzt möchten Sie eine Vorlage schreiben, die eine Liste der Hosts erstellt, die zu dieser Gruppe gehören:

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

Beachten Sie, dass die folgende Version der Vorlage nicht funktionieren würde:

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

Dies liegt daran, dass - und . in diesem Fall eine besondere Bedeutung haben. Die punktierte Notation wäre jedoch völlig in Ordnung, wenn Ihre Gruppe den Namen foo_bar_xyz denn die Vorlage lautet dann:

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

Was natürlich völlig in Ordnung ist.

Um es den Benutzern zu erleichtern, hat Ansible anscheinend immer einige Gruppennamen bereinigt. Das heißt, es war (und ist bis 2.10 noch) möglich, in den obigen Beispielen foo_bar_xyz , obwohl die Gruppe eigentlich foo-bar.xyz . Ich persönlich glaube nicht, dass das die Dinge einfacher macht und es scheint, dass das Kernteam jetzt auch damit einverstanden ist.
Ihr nächster Versuch, das Problem anzugehen, besteht also darin, "ungültige" Gruppennamen von vornherein unmöglich zu machen. Soweit ich weiß, ist es jedoch immer möglich, diese Einschränkung zu deaktivieren, indem Sie force_valid_group_names = ignore .

Lange Rede, kurzer Sinn, es sind eigentlich zwei verschiedene Änderungen, die miteinander verflochten sind[1]. Daher der verwirrende Name und Wortlaut der Warnung.

Auch hier verstehe ich das Problem nur so. Bitte korrigiere mich wenn ich falsch liege!

[1] für weitere Details siehe RFC1925 Absatz 2, Punkt (5)

Ich wollte nur meine 2¢ lassen, da ich fest auf der Seite von Bindestrichen > Unterstrichen stehe. Wenn Sie nur eine kurze Google-Suche zu diesem Thema durchführen , werden Unterstriche für jede Art von Pfad- und Kennzeichnungszwecken fast immer als unterlegen gegenüber Bindestrichen gekennzeichnet. Sie sind auch in vielen Texteditoren und Dateisystemen schwieriger zu bearbeiten.

Selbst wenn dies nicht der Fall wäre, bedeutet die Tatsache, dass ich viel häufiger Bindestriche für Dinge wie Serverbezeichnungen und Gruppen in freier Wildbahn sehe als Unterstriche, dass dies eine weitere Sache ist, die ich unbedingt zu all meinen hinzufügen muss und die ansible.cfg Dateien meiner Kunden (ich neige dazu, eine pro Playbook zu haben).

Ich habe kein Problem damit, dass Ansible versucht, eine strengere Standardeinstellung zu erzwingen, um die Erfahrung zu verbessern, aber zuerst kamen Sie wegen der Bindestriche in meinen Rollennamen (und erlaubten manchmal einzelne Ausnahmen für ältere Rollen, die zum Großvater wurden), dann kamen Sie für Bindestriche herein meine Sammlungen (sie sind in keiner Weise, Form oder Form erlaubt), und jetzt bist du gekommen, um in mein Inventar zu sprühen!

Es ist ein Krieg gegen Bindestriche da draußen ... und ich möchte irgendwo eine Grenze ziehen – in diesem Fall ist es der einzige Ort, an dem es mir tatsächlich unmöglich ist, die Verwendung von Bindestrichen zu verhindern, da viele der Anbieter von dynamischem Inventar gruppenbasierte erstellen auf Servernamen und Labels, und viele (wenn nicht die meisten) Organisationen scheinen Dinge mit Bindestrichen zu kennzeichnen (zB us-east-1a , nicht us_east_1a ).

Es macht keinen Spaß, eine Standardeinstellung zu haben, die fast immer überschrieben werden muss, damit Software funktioniert, aber es klingt so, als ob dies ab Ansible 2.11 der Fall sein wird.

Wenn es nur darum geht, dass einige Benutzer, die mit Jinja2 und Python nicht vertraut sind, nicht erkennen, dass something.with-some-dashes ungültig ist, würde ich argumentieren, dass es besser ist, ihnen beizubringen, "wenn es Gedankenstriche gibt, sollten Sie die Klammernotation für den Diktatzugriff verwenden, z. B. something['with-some-dashes'] . Sie können die beiden bei Bedarf sogar vermischen. Es ist nicht sehr rein und ganzheitlich, aber wir sind hier nicht alle Rust-Entwickler...

Sehr gut ausgedrückt, Jeff. Ich stimme Ihnen hier voll und ganz zu – diese Änderung wird so disruptiv sein und nicht nur eine einmalige Migration erfordern, sondern den Workflow einer großen Anzahl von Benutzern verändern. Ansible funktioniert nicht mehr out of the box.

Hostnamen dürfen keinen Unterstrich enthalten, in einer gesunden Welt wäre also Inventory_Hostname nicht gezwungen. Das bedeutet, dass unsere Inventare jetzt ziemlich inkonsistent aussehen, mit Hostnamen, die keine Unterstriche enthalten dürfen, und Gruppen, die keine Bindestriche enthalten dürfen.

Bitte ändern Sie einfach nicht die Standardeinstellung.

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

Hi,
Ich stimme Jeff hier voll und ganz zu.

Aber wie @bcoca oben erwähnt hat, sehen sich die meisten Entwickler diese Diskussionen hier nicht regelmäßig an und dieses Thema ist möglicherweise nicht der richtige Ort, um die Änderung zu diskutieren, da es um die richtige Dokumentation geht.

Zur Diskussion bitte dem Thread beitreten Ist es eine gute Idee, die Standardeinstellung von TRANSFORM_INVALID_GROUP_CHARS zu ändern? in Google-Gruppen.

Tolle Punkte Jeff.

Es macht keinen Spaß, eine Standardeinstellung zu haben, die fast immer überschrieben werden muss, damit Software funktioniert, aber es klingt so, als ob dies ab Ansible 2.11 der Fall sein wird.

Das ist für mich die große Erkenntnis aus all diesen Diskussionen. Ich verstehe das Problem, das gelöst werden muss, aber die Lösung scheint das Gegenteil von dem zu sein, was benötigt wird. Es macht die Sache für den Support einfacher, aber für die Benutzer schwer - das ist eine Rückwärtslösung.

Wenn es nur darum geht, dass einige Benutzer, die mit Jinja2 und Python nicht vertraut sind, etwas nicht erkennen.with-some-dashes ist ungültig, würde ich argumentieren, dass es besser ist, ihnen beizubringen, "wenn es Bindestriche gibt, sollten Sie die Klammernotation für den Diktatzugriff verwenden, z etwas['with-some-dashes']. Sie können die beiden sogar vermischen, wenn es nötig ist.

Dies hier ist die beste Lösung, keine Dinge zu zerstören, die seit Jahren verwendet wurden.

Toller Kommentar von @geerlingguy -

Ich möchte als Benutzer von Ansible hinzufügen, warum sollte ich wissen, was eine gültige Python-Syntax ist? Nachdem ich Ansible seit langer Zeit verwende, verstehe ich, dass Ansible (und seine Module) in Python geschrieben sind, aber warum sollte ich mich darum kümmern? Diese Tatsache dem Endbenutzer offenzulegen, ist einfach schlechtes Design.

Ähnlich wie das Zulassen von gültiger JavaScript/Ruby/.NET/was auch immer-Notation für Dinge wie Benutzernamen in einer Webanwendung. Warum sollte es den Endbenutzer interessieren, in welcher Sprache die Anwendung geschrieben ist?

Außerdem ist die Einführung von Breaking Changes ein schwieriges Thema, das versuche ich nach Möglichkeit zu vermeiden. Wenn ich eine Änderung vornehmen muss, belasse ich normalerweise das alte, vorhandene Verhalten als Standard und lasse die Leute sich für das neue Verhalten entscheiden. Warum wurde das hier nicht gemacht? Warum muss ich entweder meine Konfiguration oder schlimmer noch mein gesamtes Inventar ändern? Warum nicht umgekehrt?

Wenn ein System intern streng konforme Token erfordert, sollte das System intern die Token generieren und eine Nachschlagetabelle erstellen, die die internen Token den Benutzerdaten zuordnet. Auf diese Weise kann Ansible seine Token-Regeln nach Bedarf ändern und die Auswirkungen auf die Benutzer begrenzen. Benutzer sollten in der Lage sein, ihr Inventar, ihre Rollen usw. nach eigenem Ermessen zu benennen.

Mir scheint, diese Änderung kann das Gegenteil ihrer beabsichtigten Wirkung haben (um Supportanfragen zu verringern):

Jetzt wird kein Trennzeichen (standardmäßig) sowohl von Hostnamen (die DNS-auflösbar sein sollten, dh keine Unterstriche enthalten) als auch von Gruppennamen (die keine Bindestriche enthalten sollten) unterstützt.

Es sollte auf jeden Fall frei sein, alle Hosts zu benennen

El mié., vor 14 Jahren. 2019 16:16, Christian Pointner [email protected]
Beschreibung:

Wenn ich das verstehe
https://github.com/ansible/ansible/issues/56930#issuecomment-516863432
korrekt. Das einzige, was veraltet ist, ist die Automatik
Umwandlung von Gruppennamen. Dies bedeutet, dass es völlig in Ordnung sein sollte, force_valid_group_names zu setzen
= ab 2.10 ignorieren.

Es sollte auch völlig in Ordnung sein, weiterhin Bindestriche und was auch immer Sie zu verwenden
will nicht in Gruppennamen. Was Ansible in Zukunft nicht mehr tun wird, ist zu sanieren
damit Sie die punktierte Notation auch für "ungültige" Gruppennamen verwenden können. Zum
Beispiel:

Ihr Inventar enthält eine Gruppe namens foo-bar.xyz. Jetzt willst du schreiben
eine Vorlage, die eine Liste von Hosts erstellt, die zu dieser Gruppe gehören:

{% für Host in Gruppen['foo-bar.xyz'] %}
{{ Gastgeber }}
{% endfor %}

Beachten Sie, dass diese Version der Vorlage nicht funktionieren würde:

{% für Host in groups.foo-bar.xyz %}
{{ Gastgeber }}
{% endfor %}

Dies liegt daran, dass die - und die . haben in diesem Fall eine besondere Bedeutung. Die
Die gepunktete Notation wäre jedoch völlig in Ordnung, wenn Ihre Gruppe dies hätte
name foo_bar_xyz, denn die Vorlage wird dann:

{% für Host in groups.foo_bar_xyz %}
{{ Gastgeber }}
{% endfor %}

Was natürlich völlig in Ordnung ist.

Um es den Benutzern zu erleichtern, hat Ansible anscheinend immer
hat einige Hygienemaßnahmen für Gruppennamen durchgeführt. Das heißt, es war (und bis 2.10
es ist immer noch möglich, foo_bar_xyz in den obigen Beispielen zu verwenden, obwohl
die Gruppe heißt eigentlich foo-bar.xyz. Das finde ich persönlich nicht
macht die Sache überhaupt einfacher und das Kernteam scheint jetzt auch zuzustimmen
damit.
Ihr nächster Versuch, das Problem anzugehen, besteht also darin, es unmöglich zu machen
"ungültige" Gruppennamen an erster Stelle. Aber soweit ich das verstanden habe
Es wird immer möglich sein, diese Einschränkung zu deaktivieren, indem Sie force_valid_group_names festlegen
= ignorieren.

Lange Rede, kurzer Sinn, es sind eigentlich zwei verschiedene Änderungen, die vorgenommen wurden
miteinander verflochten[1]. Woher der verwirrende Name und Wortlaut von
die Warnung.

Auch hier verstehe ich das Problem nur so. Bitte korrigiere mich, wenn ich
falsch!

[1] für weitere Details siehe RFC1925
http://www.faqs.org/rfcs/rfc1925.html Absatz 2, Punkt (5)

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ansible/ansible/issues/56930?email_source=notifications&email_token=AA5N2CJCIELW7JWHC6OJ35DQEQHSPA5CNFSM4HPRGLKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMV2ZJKTcom2
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AA5N2CIVT5PLD2QCAGGBK6LQEQHSPANCNFSM4HPRGLKA
.

Das ist meiner ehrlichen Meinung nach eine wirklich falsche Entscheidung. Und das aus dem falschen Grund. Die Anzahl der Supportanfragen wirklich reduzieren?

Ansible als Werkzeug sollte dem Endbenutzer keine sprachspezifischen Details aufzwingen. Ich bin schon so verärgert darüber, dass Terraform mir all das Golang in den Rachen gedrängt hat, jetzt passiert das gleiche hier mit Ansible und dem "Pythonic"-Stil. Versteh mich nicht falsch, ich arbeite sowohl mit Go als auch mit Python recht gut, aber wenn es um Infrastruktur als Code geht, warum sollte mich das interessieren? Und was ist mit dem Versprechen passiert, dass YAML die Form der zu verwaltenden Codebasis diktiert? "Infrastruktur als Daten, die man lesen und ausführen kann", das habe ich schon so oft gehört... Soweit ich weiß, interessiert YAML weder Bindestriche noch Unterstriche.

Übrigens, es gibt ziemlich viele Dinge, die Unterstriche nicht unterstützen. Hostnamen, AWS-Regionen und IDs für buchstäblich alles, um nur einige wirklich wichtige zu nennen. Viel Glück beim Beibehalten aller Ausnahmen, bei denen die Transformation nicht stattfinden soll...

Für Leute, die hierher kommen, nur auf der Suche nach einer schnellen Lösung, um dies zu beseitigen, fügen Sie einfach die Zeile force_valid_group_names = ignore zu Ihrem ansible.cfg und seien Sie glücklich.

Nach meinem Verständnis können Sie die Punktnotation sowieso nicht für Variablen mit Leerzeichen verwenden, und obwohl ich nie Variablen mit Leerzeichen erstelle, gibt es leider viele Anbieter, die Wörterbuchschlüssel mit Leerzeichen über Json-API-Antworten zurückgeben. Die sinnvolle Option scheint mir, zur eckigen Klammernotation zu wechseln. Hoffentlich hat das Setzen von force_valid_group_names auf Ignorieren keine negativen Auswirkungen auf die Straße, wer weiß, was in Zukunft noch mit dieser Änderung geplant ist.

Dies ist eine ziemlich schreckliche Entscheidung, insbesondere wenn es darum geht, mit dynamischen Inventaren wie bei Openstack (und AWS) zu arbeiten.
Instanznamen und Metadatenschlüssel, die "verbotene Zeichen" enthalten, werden häufig als Inventarelemente und/oder Gruppenvariablen aus der zugrunde liegenden Cloud zurückgegeben. Dies wird vielen Openstack- (und AWS-)Administratoren das Leben zur Hölle machen, die versuchen, ihre Flotten mithilfe von Meta-Tags und/oder Instanz-IDs zu verwalten, wie:
Instanz-8ca09c33-f255-440f-9544-b0ab318c79d9
meta-os_ubuntu

Ansible-Entwickler sollten die Meinung von @geerlingguy ernst nehmen. Er ist einer der größten Mitwirkenden an Ansible Galaxy und seine Rollen werden von Tonnen von Menschen konsumiert. Ich denke, diese Änderung ist wirklich schlecht für Leute, die Tausende von Hosts haben, die wie folgt heißen: $env-$role-[0..99] . Sollen wir alles umbenennen, um unsere Ansible-Oberherren zu besänftigen?

@ssbarnea Zum einen machen wir einen Push, um nur Variablennamen und andere ähnliche Schlüssel zuzulassen, die gültige Python-Bezeichner sind. Um etwas mehr über Gruppennamen zu erklären, verursacht dies ein Problem für Benutzer, die versuchen, die "Punktsyntax" wie groups.foo-group , was nicht das tut, was der Benutzer erwartet. Die Anzahl der Probleme und Supportanfragen, die durch kleine Probleme wie diese verursacht werden, hat uns dazu veranlasst, einen Weg zu Sicherheitsnamen zu gehen, um sicherzustellen, dass solche Probleme nicht auftreten.

Für diejenigen, die die aus unserer Sicht ungültigen Zeichen beibehalten möchten, können Sie diese Funktion deaktivieren.

Wie lange können Benutzer dieses Verhalten deaktivieren? Wird es eine dauerhafte Konfigurationsoption geben, um dieses Verhalten in allen zukünftigen Versionen von Ansible zu deaktivieren, oder wird es nur bis 2.11 unterstützt? Ich würde mich freuen, wenn die Option standardmäßig aktiviert ist, solange ich immer die Möglichkeit habe, sie auszuschalten.

Wenn dies in 2.11+ zu einer harten Einschränkung wird, werden Sie wahrscheinlich Kunden verlieren, die an die Einschränkungen ihrer Organisation gebunden sind (nicht alle ansible-Benutzer haben die Macht, die von ihrem Unternehmen verwendeten Namenskonventionen zu diktieren). Es scheint, dass diese Änderung auch eine erhebliche Herausforderung für diejenigen darstellen würde, die eine Cloud-Infrastruktur verwenden, bei der Bindestriche in der Regel stark verwendet werden.

Nur um diejenigen zu erinnern, die hier nicht den ganzen Thread gelesen haben. Es gibt auch einen Thread auf der Entwickler-Mailingliste: https://groups.google.com/forum/#!topic/ansible -devel/bjAcM9ferIw

IMHO war diese Änderung eine wirklich schlechte Wahl. Codebreaking-Syntaxänderungen in Nebenversionen halten uns davon ab, die Verwendung von Ansible in unserer Umgebung auszuweiten. Weil ich Ansible nicht aktualisieren kann, wenn es die Playbooks meiner Benutzer beschädigt.

Aber wie @bcoca oben erwähnt hat, sehen sich die meisten Entwickler diese Diskussionen hier nicht regelmäßig an und dieses Thema ist möglicherweise nicht der richtige Ort, um die Änderung zu diskutieren, da es um die richtige Dokumentation geht.

@Tronde : Man würde argumentieren, dass Mitwirkende UND Kunden konsultiert werden, bevor Geschichten geschrieben werden, um die Auswirkungen zu verstehen und Feedback zu sammeln, bevor jemand eine Lösung kodiert. Wie mehrere hier erwähnt haben, ist dies ein Produkt-Mgmt, das wir mehr als einmal gesehen haben.

Als Beispiel für die Situation beschreibt @andyfeller diese Änderung:

Wir haben ein Problem damit auf unserer Seite.

Wir verwenden Red Hat Identity Manager als externes Inventar, wir kontrollieren es nicht, es enthält viele Hostgruppen mit Bindestrichen statt Unterstrichen. Dies wird nicht geändert (wegen all der anderen Dinge, die mit diesen Namen existieren).

Also brauchen wir:

• So konfigurieren Sie Ansible, um das aktuelle Verhalten beizubehalten
• Die Einstellungswarnung stummschalten
• Tun Sie dies für die Befehlszeile Ansible und Ansible Tower

FYI PR https://github.com/ansible/ansible/pull/66650 (bitte keine Mistgabeln dort) ist für 2.10 geplant (zum jetzigen Zeitpunkt), was bedeutet, dass jeder, der diese Warnung derzeit sieht, dies tun würde (sobald er auf 2.10 aktualisiert, wieder unter der Annahme, dass PR zusammengeführt wird) beginnen stattdessen mit Playbook-Fehlern (bis sie force_valid_group_names = ignore in einem ansible.cfg ).

Nur zur Sichtbarkeit posten. Ich stehe immer noch fest hinter meiner früheren Behauptung, dass dies eine benutzerfeindliche Standardeinstellung ist, da es immer noch viele dynamische Inventarskripte gibt (ein Teil von Ansible selbst oder jetzt in "offizielle" Sammlungen verschoben), die Gruppennamen mit Bindestrichen generieren oder andere gültige DNS-Zeichen.

Praktisch jeder, der Ansible mit AWS verwendet, muss die Standardeinstellung überschreiben.

@geerlingguy Ist das die richtige PR-Nummer? Sieht so aus, als ob das auf dieses Problem hindeutet.

Zu Ihrer Information, dies wurde hier auf einem Core Meeting besprochen, beginnend bei 19:06:55

@apple4ever oops, habe den Link aktualisiert, er ist https://github.com/ansible/ansible/pull/66650

Ich habe oben viele Kommentare von Dingen gesehen, die bereits beantwortet / entlarvt / etc. waren, also verlinke ich hier einfach meinen vorherigen Beitrag.

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

Bitte fügen Sie keine neuen Beiträge hinzu, die keine NEUEN Elemente zur Diskussion hinzufügen, da sie die vorherigen, die bereits beantwortet wurden, ausblenden.

Übrigens, wo wäre ein guter Ort, um in der Python-Dokumentation zu verlinken, wie gültige Variablennamen aussehen? Es gibt https://docs.python.org/3/reference/lexical_analysis.html#gramar -token-identifier, aber das ist für Leute ohne Informatik-Hintergrund nicht wirklich benutzerfreundlich oder lesbar.

Der Grund für die Nachfrage ist, dass ich nicht sicher bin, ob die eigentliche Erstbeschwerde tatsächlich bearbeitet wurde. Es gibt nur eine Warnung, dass etwas nicht stimmt, aber es erfordert viel Recherche, um herauszufinden, was genau und wie man - wenn es will oder kann - tatsächlich einen gültigen Gruppennamen wählen könnte. Ich würde zumindest ein klares "Der Gruppenname foo-bar enthält ungültige Zeichen ( - ). Gültige Gruppennamen sollten gültige Python-Bezeichner sein (siehe https://docs.python.org/??? für weitere Informationen)" erwarten. nicht nur "es gibt schlechte Zeichen, überprüfen Sie noch einmal mit -vvvv, um herauszufinden, welche!". Idealerweise würde dies auch erwähnen, dass dies deaktiviert werden kann, aber zu anderen unerwarteten Problemen führen könnte (wie es Ansible wirklich schwer macht, die Gruppen foo-bar , foo.bar und foo_bar ).

Derzeit ist es eher eine "Sie haben etwas falsch gemacht, beheben Sie es"-Meldungen ohne klare Vorgehensweise, was auch zu der starken Resonanz hier beigetragen haben könnte.

@geerlingguy schrieb im Kommentar 56930 :

(bis sie force_valid_group_names = false in einer ansible.cfg setzen)

Die Dokumentation erwähnt 'false' nicht als gültigen Wert für diesen Schlüssel. Ich habe den Wert auf 'ignore' gesetzt, was den Zweck erfüllen sollte. Aber ist 'false' ein ungültiges Schlüsselwort oder ist es richtig und die Dokumentation ist hier nicht vollständig?

@bcoca in einem früheren Kommentar:

Um es nur einmal klar zu sagen, SIE WERDEN IMMER IN GRUPPENNAMEN Striche verwenden können, auch Punkte und andere Zeichen, die jetzt als "ungültig" gelten, nur nicht standardmäßig. Diese 'Standardeinstellung' ist veraltet, die Standardeinstellung ist in 2.11 'sicher', aber Sie haben immer die Möglichkeit, sich für das alte Verhalten zu entscheiden.

Sie haben wiederholt erklärt, dass das aktuelle Verhalten beibehalten werden kann, aber was sind die genauen Einstellungen von ansible.cfg, um dies _jetzt_ zu tun und die Veraltungswarnung zu unterdrücken?

Ich habe es versucht, wie @geerlingguy in Kommentar 56930 schrieb:

(bis sie force_valid_group_names = false in einer ansible.cfg setzen)

Was dazu führt, dass meine Playbooks fehlschlagen, wenn sie keine Hosts oder Gruppen mit Bindestrichen finden können (sie kommen von einem Inventar-Plugin, das wir übrigens geschrieben haben, müssen diese auch die Transformation durchführen oder wird dies getan, wenn Ansible das Inventar von aufnimmt? das Plugin?)

Ich habe es versucht, wie @geerlingguy in Kommentar 56930 schrieb:

(bis sie force_valid_group_names = false in einer ansible.cfg setzen)

Was dazu führt, dass meine Playbooks fehlschlagen, wenn sie keine Hosts oder Gruppen mit Bindestrichen finden können (sie kommen von einem Inventar-Plugin, das wir übrigens geschrieben haben, müssen diese auch die Transformation durchführen oder wird dies getan, wenn Ansible das Inventar von aufnimmt? das Plugin?)

Dies wurde in mehreren Kommentaren erwähnt und steht in der Dokumentation . Sie sollten nie verwenden oder ignorieren .

Sollen wir also das dynamische Inventarskript EC2 nicht mehr verwenden, da es alles nach 'us-east-1', 'us-east-2' usw. gruppiert? Oder ist eine Aktualisierung geplant? Ich habe gerade die Dokumentation von Ansible für das dynamische Inventarskript EC2 aufgerufen und der Link zum Herunterladen auf Github funktioniert nicht mehr, das ist also interessant.

Ich habe gerade die Dokumentation von Ansible für das dynamische Inventarskript EC2 aufgerufen und der Link zum Herunterladen auf Github funktioniert nicht mehr, das ist also interessant.

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

Für diejenigen unter euch, die sich nicht die Mühe machen, das IRC-Log zu lesen, hier die Entscheidung, dh keine Entscheidung:

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

ja, jemand hat geschrieben "können Sie gerne bei ML oder IRC vorbeischauen". nein, "dieses Projekt ist keine Demokratie".

ja, jemand hat geschrieben "können Sie gerne bei ML oder IRC vorbeischauen". nein, "dieses Projekt ist keine Demokratie".

Um ehrlich zu sein, ist das bei OpenSource falsch - Wenn es zu einem nicht populären Weg führt - können die Leute es abzweigen, kann es abgezweigt werden?

Ich kann sehen, dass das Akzeptieren von PR in Ansible schrecklich langsam ist. Patches scheinen offensichtlich notwendig und einfach zu ändern, aber es kommt nie rein. Glücklicherweise ist Ansible selbst flexibel, um es den Leuten zu ermöglichen, benutzerdefinierte Plugins zu verwenden, aber es scheint, dass veraltete Beiträge weniger oder sogar mehr Aufwand bedeuten.

Ich bin ein bisschen traurig, wirklich ...

@sunshine69 Ich fühle deinen Schmerz. Aber das ist eine Diskussion, die im IRC oder der Google Group for Ansible Development stattfinden sollte.

Dieses Thema ist nicht der richtige Ort dafür. Denn zu wenige Leute lesen hier.

@sunshine69 Ich fühle deinen Schmerz. Aber das ist eine Diskussion, die im IRC oder der Google Group for Ansible Development stattfinden sollte.

Dieses Thema ist nicht der richtige Ort dafür. Denn zu wenige Leute lesen hier.

Während die Diskussion in diesen anderen Kanälen produktiver sein könnte, wird die Transparenz für diejenigen geschätzt, die dieses Thema speziell verfolgen. IRC ist schließlich nicht jedermanns Sache.

Zu Ihrer Information :

In der Beschreibung identifizierte Dateien:

• lib/ansible/modules/group.py

Wenn diese Dateien falsch sind, aktualisieren Sie bitte den Abschnitt component name der Beschreibung oder verwenden Sie den Bot-Befehl !component .

Klicken Sie hier für Bot-Hilfe

Als ich eingestellt force_valid_group_names = ignore ging die Warnung weg, aber die deprecation BEKANNTMACHUNG ging nicht weg.

Schließlich habe ich in den Dokumenten gefunden: force_valid_group_names = silently das den Ersatz durchführt und die Ausgabe nicht verstopft - wenn Sie das tun möchten.

Nichtsdestotrotz hätte dieses ganze Problem von vornherein vermieden werden können, wenn sinnlose Änderungen wie diese nicht von vornherein vorgenommen worden wären.

@emmm-dee - Für dieses spezielle Problem habe ich https://github.com/ansible/ansible/issues/70908 geöffnet. Beachten Sie, dass dieses Problem weiterhin besteht, da es noch keine offizielle Dokumentation für _sind_ 'gültige' Gruppenzeichen gibt .

danke an @geerlingguy für deine Aktionen! Sie sind derjenige, der Ansible besser macht.

Ich arbeite für unsere Anwendung für Bounce (Start/Stopp), aber ich bin nicht mit dem Anwendungshost verbunden.

Ich habe den Ping-Befehl ausprobiert, den Sie gesendet haben, und es funktioniert ...

[ webadmin@vlodjumpts00 ~]$ ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) Datenbytes.

64 Byte aus 8.8.8.8: icmp_seq=1 ttl=112 Zeit=10.6 ms

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

-bash: mirrorlist.centos.org: Befehl nicht gefunden

Ich möchte dies für unsere Organisation verwenden.. wenn ich den Befehl "ansible all -m ping" ausgeführt habe. mit Fehler konfrontiert, unten sind Details:

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

ändern, aber nach wie vor vom Benutzer konfigurierbar sein. Diese Funktion wird in Version 2.10 entfernt. Einstellungswarnungen können sein

deaktiviert durch Setzen von deprecation_warnings=False in ansible.cfg.

RTE3EPAdmin | UNERREICHBAR! => {

"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 | ERFOLG => {

"ansible_facts": {

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

},

"changed": false,

"ping": "pong"

}

Bitte helft mir... was ich dazu brauche. Tatsächlich haben wir keine UN/PWD für Hosts-Datei zum Verbinden des Host-Computers.

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:Kinder]

RTE3VFO

RTE3EP

RTE3RES

RTE3ORCH

RTE3EASE

RTE3RTS

und die Verzeichnisstruktur ist:

[ webadmin@vlodjumpts00 ansible]$ pwd

/etc/ansible

[ webadmin@vlodjumpts00 ansible]$ ll

insgesamt 84

-rw------- 1 Webadmin Webadmin 607 12. Juli 2017 1

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

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

-rw------- 1 webadmin webadmin 213 3. Juli 2017 easyasr-rte2-ease.yml

-rwxr-xr-x 1 Webadmin Webadmin 1034 Sep 19 09:16 Ease-Hosts

-rwxr-xr-x 1 Webadmin Webadmin 1647 Sep 19 10:50 Hosts

-rw------- 1 webadmin webadmin 2679 3. Juli 2017 hosts.bkp

-rw------- 1 webadmin webadmin 273 6. Juli 2017 lineinsfile_tst.yml

drwx------ 4 webadmin webadmin 4096 2. November 2017 Playbooks

drwxr-xr-x 3 root root 19. Dezember 8 2019 Rollen

-rwxr-xr-x 1 webadmin webadmin 7321 2. November 2017 servmix_hosts

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

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

Wir sind nicht direkt mit dem Host verbunden... Loggen Sie sich zuerst auf unserem Jump-Server ein und dann ssh-Host...

Jump-Server ist "vmdcltctws217" Port mit =22, Verbindungstyp=ssh

und dann mit unserem UN/PWD eintreten

Danach haben wir Sudo für die Verbindung zum Hostserver gemacht.

sudo su - easesqa

und dann ssh-hostserver wie ..

vlddwblasts001.test.intranet

dann führen wir den start/stop-Befehl von hier aus aus..

Bitte helft mir, wozu kann ich das tun?