الملفات المحددة في الوصف:

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

إذا كانت هذه الملفات غير دقيقة ، يرجى تحديث قسم component name للوصف أو استخدام الأمر !component bot.

انقر هنا للحصول على مساعدة الروبوت

ccsfromm
انقر هنا للحصول على مساعدة الروبوت

لقد بدأت في تلقي هذا التحذير ولكن لم أجد أي مراجع في دليل النقل ولا توجد مراجع لكيفية الإصلاح أو ما يجب إصلاحه.

معظم تحذيراتي من ec2.py ، حيث استخدم معرف المثيل - (على سبيل المثال: 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 لسبب واحد ، نحن نقوم بالدفع للسماح فقط بأسماء المتغيرات ، ومفاتيح أخرى مماثلة ، والتي تعد معرّفات بيثون صالحة. لتوضيح المزيد حول أسماء المجموعات ، يتسبب ذلك في مشكلة للمستخدمين الذين يحاولون استخدام "بناء الجملة" مثل 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 غير الثابت:

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

تم تعريف هذه الأحرف غير الصالحة (اعتبارًا من 2019-06-04) على أنها ثابتة ، 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- أو أمر ad-hoc ansible عن طريق إضافة deprecation_warnings = False إلى نفس [defaults] قسم من ansible.cfg ، ولكن أنصح ضد ذلك (منذ كنت قد يغيب عن أخبار مهمة)، وبدلا من استخدام المتغيرات قذيفة البيئة المضمنة مثل هذا:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

ومع ذلك ، لن يختفي تحليل المخزون [WARNING] s. لا يوجد config أو env var محدد لإيقاف جميع التحذيرات (حتى الآن؟) ، ولكن إذا كان هذا يزعجك حقًا ، يمكنك فقط إرسال كل stderr إلى /dev/null (أدخل تحذيرات "أفضل الممارسات" هنا):

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

أتمنى أن يساعد هذا شخص ما في مكان ما.

أجد رسائل التحذير من الإيقاف مزعجة فقط عندما لا توفر مسار ترحيل. بالنظر إلى أن المساحة محدودة وأنه من المحتمل أن يحتاج الإصلاح إلى تحديث ، أجد أنه من المفيد جدًا توفير روابط للتذاكر التي يمكنها توثيق الحلول والحلول البديلة ...

يمكن لمقاربة كهذه توفير العمل الإضافي اللازم لتحسين رسائل التحذيرات غير المكتملة حيث لن نضطر إلى تحديث الرسالة ، أو إعادة نقلها إلى إصدارات قليلة.

ملاحظة. إن تعطيل تحذيرات الإهمال أمر لا أوصي به لأي شخص ، ربما فقط إذا كان المشروع يواجه بالفعل مصيره النهائي ؛)

لقد بدأت في تلقي هذا التحذير ولكن لم أجد أي مراجع في دليل النقل ولا توجد مراجع لكيفية الإصلاح أو ما يجب إصلاحه.

معظم تحذيراتي من ec2.py ، حيث استخدم معرف المثيل - (على سبيل المثال: 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 لتعطيل تجميع المضيفات عن طريق example_id ( group_by_instance_id = False ) ، لكن الإعداد الذي لم يحل التحذير بالنسبة لي كما توقعت - لقد تأكدت من أنني مسح ذاكرة التخزين المؤقت للمخزون المحلي.

أي حلول للمخزون الديناميكي EC2 على وجه التحديد؟

تم تعريف هذه الأحرف غير الصالحة (اعتبارًا من 2019-06-04) على أنها ثابتة ، 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- أو أمر ad-hoc ansible عن طريق إضافة deprecation_warnings = False إلى نفس [defaults] قسم من ansible.cfg ، ولكن أنصح ضد ذلك (منذ كنت قد يغيب عن أخبار مهمة)، وبدلا من استخدام المتغيرات قذيفة البيئة المضمنة مثل هذا:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

ومع ذلك ، لن يختفي تحليل المخزون [WARNING] s. لا يوجد config أو env var محدد لإيقاف جميع التحذيرات (حتى الآن؟) ، ولكن إذا كان هذا يزعجك حقًا ، يمكنك فقط إرسال كل stderr إلى /dev/null (أدخل تحذيرات "أفضل الممارسات" هنا):

يوفر الخيار ignore غير الموثق هذه الوظيفة. Docs PR هنا: https://github.com/ansible/ansible/pull/57318

بدءًا من الإصدار 2.8.2 ، سيتم سحق تحذير الإيقاف هذا إذا قمت بتعيين أي من الاختيارات بشكل صريح.

أين يناقش فريق التطوير أنسبل هذا النوع من القرارات؟ يصعب علينا نحن المستخدمين فهم أسباب ذلك. إذا كان المنطق "أسلوب بيثون" خالصًا ، وليس تفكيرًا عمليًا ، فقد يكون من المفيد إعادة النظر فيه؟ إذا كانت الشرطة في أسماء المجموعات تكسر الأشياء في الإصدارات المستقبلية من ansible ، فقد تكون مشكلة في التنفيذ ، أكثر من تسمية مجموعة؟

بالنسبة لي ، هذا يبدو وكأنه تغيير تجميلي أكثر من كونه شيئًا تم التفكير فيه بشكل صحيح.

اسم المجموعة ليس اسم متغير ، بل هو محتوى مثل هذا. الواصلة / الشرطة هي مجرد حرف ، وهي أيضًا طريقة شائعة جدًا لتجميع المعلومات في اصطلاح تسمية. مقارنة بعلامة التعجب أو النجمة ، فليس لها معنى خاص في شرط التحديد.

تكلفة التخفيف من هذه المشكلة باهظة ، نظرًا لأن الآلاف من المواقع لا يتعين عليها تغيير أسماء المجموعات في قوائم الجرد فحسب ، بل يتعين عليها أيضًا مراجعة جميع كتيبات اللعبة والأدوار المحلية الخاصة بهم ، واختبارها جميعًا مرة أخرى.

إذا كان هناك أي طريقة على الإطلاق تجعل "الفلاحين" صوتهم مسموعًا ، أود أن أشير في رأيي وأن أحاول أن أفهم كيف ظهرت هذه الفكرة.

لقد فهمت أن التغيير تم إجراؤه على "غير ممكن" لأن المستخدمين ارتكبوا أخطاء مثل محاولة استخدام groups.group-name بدلاً من groups['group-name'] . AIUI ، هو تغيير لغرض تقليل مشكلات الدعم فقط. (أنا شخصياً أعارض التغيير).

السلوك القديم لن يزول. سيصبح غير متاح دون اختيار السلوك القديم صراحة.

المحزن أن نسمع.

حالة الاستخدام الخاصة بي ، هي أنني أقوم بتضمين الأمر "مخزون غير مقبول" في ملف 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 ، لذا فإن هذا التغيير سيستغرق الكثير من الجهد لمحاربة ذاكرة العضلات.

لست متأكدًا مما إذا كانت إضافة أنا أخرى

الرجاء دعم الواصلات مع الأحرف والأرقام والشرطات السفلية في أسماء المجموعات (ولكن ليس لدي أي شيء مقابل النقاط أيضًا)!

نحن نستخدم الواصلات بكثرة في أسماء المجموعات. كلاهما لتجميع الأسماء مثل هذا:

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

و _abuse_ المخزون للاحتفاظ بقائمة المضيف في مكان واحد (بدلاً من الاحتفاظ بأسماء المضيف في ملفات var مختلفة) مثل هذا:

[prometheus_node-exporter_cluster1:children]
server-3x
server-5x
````
We use such groups in templates like this:

{٪ set _hostgroup = [_service، _job، _cluster] | انضمام ('_')٪}
{٪ set _hostlist = المجموعات [_hostgroup] | d ([]) | فرز٪}
{٪ if _hostlist٪}
{٪ للمضيف في _hostlist٪}
...
""

نحن لا نستخدم النقاط لمجرد عمل اختلافات واضحة بين أسماء المجموعة والمضيف.

كلمة غير صالحة في TRANSFORM_INVALID_GROUP_CHARS لا تعطي أي ثقة بأنه من الممكن الاستمرار في استخدامها على المدى الطويل.

إذا كان القصد هو تجنب استخدام هذه الأحرف ، فمن الأفضل تسميتها _UNSAFE_ الأحرف ، وإظهار التحذير والسماح للمستخدمين بتحديد ما إذا كانوا يرون هذا التحذير أم لا. لكن لا ترفض أبدًا أو تستبدل هذه الشخصيات!

يجب على المستخدمين أ) تجاهل هذا التحذير (باستخدام كلمة رئيسية مثل ALLOW_UNSAFE_GROUP_CHARS) ، ب) تغيير أسماء مجموعاتهم (عند الإمكان) أو ج) التعايش مع هذا التحذير فقط. سيختار معظمهم بين أول خيارين على أي حال.

أشعر أيضًا أن هذا لا طائل من ورائه ، حيث أن الشرطة "-" هي حرف محدد معياري يستخدم تقريبًا في كل نوع من الأدوات المتعلقة بالحاسوب ، ومحاولة التوافق مع "دين" واحد يبدو مقيدًا !!!

السلوك القديم لن يزول. سيصبح غير متاح دون اختيار السلوك القديم صراحة.

لن أكون قلقًا بشأن هذا الإهمال إذا كان من الممكن فعلاً الاشتراك في الشرطات في أسماء المجموعات. ثم قد يكون مفهومًا من منظور المستخدم الجديد.

ومع ذلك ، يشير تحذير الإيقاف إلى أن الخيار TRANSFORM_INVALID_GROUP_CHARS=never سيختفي في Ansible 2.10 ، ولذا سنحتاج إلى البدء في إعادة تسمية جميع مجموعاتنا قبل إصدار Ansible 2.10؟

[DEPRECATION WARNING]: تم تعيين إعدادات TRANSFORM_INVALID_GROUP_CHARS للسماح بالأحرف السيئة في أسماء المجموعات افتراضيًا ، وسيتغير هذا ، لكن يظل المستخدم قابلاً للتكوين عند الإيقاف. ستتم إزالة هذه الميزة في الإصدار 2.10. يمكن تعطيل تحذيرات الإيقاف عن طريق تعيين devecation_warnings = False in ansible.cfg.

أيضًا ، يؤدي استخدام المكون الإضافي للمخزون الديناميكي keyed_groups إلى تحويل أسماء المجموعة ، حتى إذا تم تعيين TRANSFORM_INVALID_GROUP_CHARS=never : https://github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/ الإضافات / المخزون / __ 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 بدلاً من المجموعات ["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 مجموعاتي مع الشرطات دون تقديم شكوى.

ها هي النتائج بدون :

[DEPRECATION WARNING]: تم تعيين إعدادات TRANSFORM_INVALID_GROUP_CHARS للسماح بالأحرف السيئة في أسماء المجموعات افتراضيًا ، وسيتغير هذا ، لكن يظل المستخدم قابلاً للتكوين عند الإيقاف. ستتم إزالة هذه الميزة في الإصدار 2.10. الاستنكار
يمكن تعطيل التحذيرات عن طريق تعيين devecation_warnings = False in ansible.cfg.
[تحذير]: تم العثور على أحرف غير صالحة في أسماء المجموعات ولكن لم يتم استبدالها ، استخدم -vvvv لمشاهدة التفاصيل

ومع ضبط الإعداد على "خطأ" في 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)

لكن هل هو مجرد تحذيرات سحق ، أم هل سيسمح لنا ذلك بالاستمرار في استخدام الشرطات في مجموعات؟
هذا ليس واضحا جدا.

أنا أتفق مع كل المنتقدين هنا.

بالإضافة إلى كسر قواعد اللعبة ، يساهم هذا في ما أسميه فوضى الاتفاقية في غير مسموع. الآن أسماء المضيفين وأسماء المجموعات لها اصطلاح مختلف ، فقط لأن بعض المبتدئين المعزولين يعثرون على مشكلة الواصلة في تدوين النقطة؟ خمين ما ؟ لا يزالون يتعثرون فيه ، وستنجح الميزة في إثارة غضب الناس وعدم حل أي مشكلة. أحسنت.

يجب أن تكون أسماء المجموعات التي لا يمكن قبولها قادرة على احترام تسمية مجموعات العالم الحقيقي التي تمثلها.

إذا كانت جميع الأدوات الأخرى تستدعي مجموعة من المضيفين my-backend-service لماذا يجب أن يجبر المشغلون على ترجمة ذلك إلى my_backend_service لتلبية قواعد تسمية Python.

إنه يوم حزين حقًا اليوم .. عندما أثار لي أحد زملائي في JR هذا الاستنكار لي ، لم أشعر بأي حال من الأحوال أن فريق Ansible سيكون بعيدًا عن الواقع لاتخاذ مثل هذا الاختيار الأناني. أنا أحب Ansible تمامًا لما يمكنها إنجازه (من منظور المستخدم الذي لا علاقة له بأي شيء يتم كتابته بلغة Python) الاتجاه هنا لدفع معايير PEP على المستخدمين النهائيين يجعلني أفقد تمامًا الإيمان بقدرة فريق التطوير الأساسي Ansible على صنع قرارات عقلانية. آمل أن تقوم شركة IBM بتصحيح ذلك ..
أو
ربما سيكون هناك مكافئ GO لامع جديد يمكننا الانتقال إليه.

بما أن هذا السلوك مثير للجدل بشكل واضح ، فأنا أسأل نفسي ما إذا كانت هذه صفقة محسومة ، وسيتم تنفيذ هذا على أي حال؟

سأكون ممتنًا جدًا للرد من الأشخاص الذين يقفون وراء هذا القرار وآمل في بعض التفاصيل بخلاف "هذا شيء قياسي من نوع بيثون".

بما أن هذا السلوك مثير للجدل بشكل واضح ، فأنا أسأل نفسي ما إذا كانت هذه صفقة محسومة ، وسيتم تنفيذ هذا على أي حال؟

سأكون ممتنًا جدًا للرد من الأشخاص الذين يقفون وراء هذا القرار وآمل في بعض التفاصيل بخلاف "هذا شيء قياسي من نوع بيثون".

أنا أتفق معك. مؤخرًا ، تم دعم مشروع "go" من اقتراح غير محبوب (راجع https://github.com/golang/go/issues/32437#issuecomment-512035919) ، لذلك يمكن (وأحيانًا يجب) إعادة النظر في أشياء كهذه وفي النهاية كما تراجع.

إنه أيضًا موضوع ومناقشات مثيرة للاهتمام ، ربما ليس فقط لتغيير هذه الميزة. من الصعب معرفة كيفية عمل حوكمة أنسبل كمنتج. ربما يجب على شخص ما إحضار شيء معهم إلى https://www.ansible.com/ansiblefest ؟

نظرًا لأن الكثيرين منا يخدشون رؤوسنا ، ولا يفهمون كيف يمكن لسلسلة / محتوى متغير / اسم مجموعة بأي شكل من الأشكال أن يطرح أي مشاكل مع أنماط ترميز Python ، سيكون من الجيد الحصول على رد هنا من المشرفين ، بحجة سبب ظهور ذلك قضية.

أستطيع أن أفهم ما إذا كانوا يريدون الاحتفاظ بنمط ترميز لأسماء وهياكل المتغيرات ، ولكن محتوى مصفوفة أو متغير؟

فيما يلي مناقشة سريعة حول التدوين النقطي للإملاءات. إنه ممكن ، لكنه قبيح. https://stackoverflow.com/questions/16279212/how-to-use-dot-notation-for-dict-in-python

حقيقة وجود مشكلات دعم تحيط بهذا الأمر في رأيي هي مشكلة في التوثيق وليست مشكلة وظيفية. إذا كان هناك أي شيء أود أن أجادل فيه أن أسماء المجموعات لا ينبغي أن تكون متغيرات.

كما هو الحال مع حقيقة أن هذا التغيير تم تنفيذه قبل توفر / توفر أي وثائق.

ما هو تأثير هذا التغيير؟ هل يتعين علي تعديل جميع قوائم الجرد غير المرغوبة بعناية للتأكد من عدم وجود شرطات في أسماء المجموعات؟

CMoH IMO أفضل حل في الوقت الحالي هو إضافة force_valid_group_names = ignore إلى التكوين الخاص بك وتشغيل 2.8.2 أو أحدث.

skyscooby ، حتى هذا بيتا. الشيء الذي لا يمكن وضع هذا السطر فيه كإعداد افتراضي في /etc/ansible.cfg واستخدام ansible.cfg المحلي في أدلة playbook للتكوين الآخر. هذا يعني أنه يجب تغيير جميع ملفات ansible.cfg التي تم الخروج منها.

أو هل هناك أي طريقة لإعداد الافتراضات العامة (بدون إضافة متغير آخر إلى بيئة المستخدم)؟

وافق Cougar على هذا الاختيار من Ansible هو بيتا ..

ومع ذلك ، فإن مشكلتك ليست فريدة من نوعها في هذا الإعداد .. لقد واجهنا ألمًا مشابهًا والآن لا نشجع استخدام ملفات ansible.cfg لكل مشروع حيث يمكن ضبط معظم الإعدادات باستخدام متغيرات البيئة التي تتجاوز إعدادات ملف cfg .. لذلك إذا كانت هناك مشروعات لـ يحتاج بعض الأسباب الغامضة إلى إعداد محدد نطلب منهم استخدام طريقة ENV التي تترك بقية الإعدادات التي لا يحتاجون إلى تغييرها لتتوافق مع معايير الشركة. نحن نبني حاوية قاعدة إرساء بهذا التكوين القياسي والمشاريع الفردية ببساطة تضيف إدخالات ENV إلى Dockerfile الخاص بها أثناء إنشاء صورتها للحاوية الأساسية غير الصالحة. يتم تنفيذ جميع العناصر غير القابلة للكسر داخل الحاوية ، لذا فنحن على يقين من أن جميع وحدات النقطة والإصدارات المتوافقة وأدوات وقت التشغيل متطابقة تمامًا.

تحرير: يمنحنا هذا أيضًا القدرة على تنظيم إصدارات جديدة من مشكلات 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 مرات عديدة الآن.

كما أفهمها ، تم تعقيم أسماء المجموعات سابقًا في المكونات الإضافية والأساسية ، وقرر شخص ما (لأي سبب كان ، لأنه لا يزال غير واضح على الإطلاق بالنسبة لي) ، أن أسماء المجموعات يجب أن تتبع اصطلاحات تسمية متغير بايثون.

لذا فقد دفع # 52748 الصرف الصحي إلى المخزون بدلاً من ذلك ، مما يكسر الأشياء لكثير من الناس. خاصةً الأشخاص الذين يستخدمون اصطلاحات التسمية الذكية ، على سبيل المثال في AWS و Azure وما إلى ذلك ، لتعيين المضيفين إلى المجموعات.

إذا أردنا استخدام نفس المعيار / اصطلاح التسمية لأسماء المضيفين ، فإننا بالتأكيد نفقد الزخم ونفقد المستخدمين.

اسم المجموعة هو اسم وليس متغير. استخدام الشرطات في أسماء المجموعات (تمامًا كما في أسماء المضيف) أمر منطقي. لا ينبغي أن تتم الترجمة (الصرف الصحي) على مستوى المخزون (من جانبنا ، نحن المستخدمون) ، وفي أفضل العوالم أبدًا.

أنا حقًا لا أرى فائدة من فرض هذا. يبدو أن المناقشة تغطي أيضًا "." و ":" ، والتي يفضل بعض الأشخاص استخدامها في أسماء المجموعات. أنا شخصياً لا أستخدمها ، لكنني أيضًا لا أرى الضرر في القيام بذلك.

طالما أن موفري السحابة يستخدمون الشرطات في معلوماتهم الوصفية ، يجب أن نكون قادرين على استخدامها للتجميع. في الواقع ، لا ينبغي حتى أن يكون السائق. إذا كنت أرغب في تسمية مجموعة باسم abcde ، فلا ينبغي أن تكون هذه مشكلة بالفعل. إنه محدد مفيد للغاية.

ومع ذلك ، لا يبدو أن هذا الموضوع يجذب أي اهتمام من المطورين أو المشرفين. أعتقد أننا نتحدث إلى آذان صماء.

Devs / Maintainers: من فضلك ، أيها الجميل ، يرجى السماح بالشرطات في أسماء المجموعات!

لتوضيح بعض المفاهيم الخاطئة ، كان جزء منها بسبب أخطائي وجعل الرسائل الأولية غير واضحة ، تحتوي الإصدارات الأخيرة على إصلاحات لبعض المشكلات التي يواصل الأشخاص طرحها هنا ، ولا تزال هناك إصلاحات أخرى:

فقط لقول هذا مرة واحدة ، من الواضح أنك ستكون دائمًا قادرًا على استخدام الدُش في أسماء المجموعة أيضًا النقاط والأحرف الأخرى التي تُعتبر الآن "غير صالحة" ، ولكن ليس افتراضيًا. هذا "الافتراضي" هو ما يتم إهماله ، سيكون الإعداد الافتراضي "آمنًا" في 2.11 ، ولكن سيكون لديك دائمًا خيار "الاشتراك" في السلوك القديم.

ولتوضيح كيف ولماذا وصلنا إلى هنا:

أولاً ، تم تعقيم أسماء المجموعات دائمًا ، وكان لديهم قواعد مختلفة غير متسقة ، اعتمادًا على نوع المخزون الذي كنت تستخدمه ، وكانت النصوص في كل مكان ، وفعلت كل من تنسيقات YAML و INI ما تريده. كان التغيير الرئيسي هو "مركزية وتطبيع الصرف الصحي" ، وقد تقرر ذلك مرة أخرى في 2.4 ولكن لم يتم تنفيذه بالكامل حتى 2.8. كان القصد هو توفير معيار أو خط أساس يمكن للجميع استخدامه بأمان في Ansilbe ، والذي قال إننا ندرك أن هناك العديد من الأشخاص الذين يستخدمون أحرفًا "غير آمنة" أو "غير صالحة" للمتغيرات ، لذا فقد جعلنا هذا قابلًا للتكوين ، ليس فقط عالميًا ولكن أيضًا من قبل بعض إضافات المخزون.

كان للتنفيذ الأولي بعض المشكلات والكثير من المناقشات (لا ، لم نقرر هذا في الاختباء ، لدينا اجتماعات عامة في irc نرحب بكم جميعًا ، https://github.com/ansible/community/blob/master /meetings/README.md) وتم دمج الكثير من التعليقات (يتم تسجيلها أيضًا حتى تتمكن من العودة لمشاهدة المناقشات والاستدلال ، ولكن لتجنب "الغوص في سجل النفايات" ، سأشرح معظم المشكلات أدناه) . بعد الخروج في 2.8 ، حصلنا على جولة أخرى من التعليقات وقمنا بإصلاح بعض الأخطاء ، مثل الحصول دائمًا على الإهمال ، ليس فقط عند استخدام الافتراضي وخاصة مع صياغة الوثائق والتحذيرات.

• "لماذا أسماء بايثون؟"
  غالبًا لأن Ansible يستخدم Python و JInja (والذي يستخدم أيضًا Python) وبعض استخدامات المجموعات (غالبًا في الأمثلة المبكرة لدينا ، ولكن أيضًا الكثير من أمثلة الأطراف الثالثة) يمكن أن تخلق أخطاء في قواعد اللعبة ، مثل stuff: '{{ groups.gropup-name-with-dash ... }}' أو أسوأ من group.name.with.dots . يؤدي هذا إلى حدوث ارتباك للعديد من المستخدمين الذين يرغبون في استخدام ميزة Jinja الخاصة بـ "تدوين النقطة للوصول المتغير" وهذا هو السبب في أن الإعداد الافتراضي يجب أن يكون آمنًا لجميع المستخدمين. قد لا يتفق معظم الأشخاص في هذا المنشور مع هذا ، ولكن هذه مشكلة حقيقية لكثير من الأشخاص ولا ينبغي أن تكون "فخًا" في انتظار مستخدمي Ansible الجدد أو القدامى. ومن ثم ، فإن أولئك الذين "ينسحبون" يكونون مسؤولين عن تجنب تعطل الاستخدام في أجزاء أخرى من Ansible.

• "ماذا لو أحببت أن كل مخزون يحتوي على صرف صحي مختلف؟"
  حسنًا ، لا يزال بإمكانك إيقاف تشغيل الصرف الصحي "المركزي" وتمكينه لمصدر المخزون المحدد الخاص بك ، وقد تمت إضافة خيارات إضافية لمكونات المخزون الجديدة الأكثر شيوعًا التي تحل محل البرامج النصية القديمة لمحاكاة سلوك البرنامج النصي ، أسوأ سيناريو ، لا يزال بإمكانك استخدام مخطوطات الجرد.

• "لماذا لا تكون أسماء المضيف / أسماء المضيف بعد ذلك؟"
  كما هو الحال بالنسبة للمجموعات ، لطالما كان التطهير لأسماء المضيف موجودًا ، ولكنه لم يتغير ، ولأسماء المضيف متطلبات مختلفة ، مثل إمكانية حل DNS
  لاتصالات الشبكة أو مسار صالح لاتصالات chroot. أيضًا ، لحسن الحظ ، هناك أمثلة قليلة أو معدومة على استخدام أسماء المضيف في تدوين النقاط ، لم تكن هذه ممارسة شائعة وستصبح مشكلة إذا بدأ الناس استخدامها فجأة ، ولكن على عكس أسماء المجموعات ، هذا شيء تجنبناه حتى الآن. إذا أصبحت مشكلة في المضي قدمًا ... لا أرى حلاً جيدًا أيضًا.

لاحظ أن هذه التذكرة المحددة (ليست وصفًا / معلومات جيدة بما يكفي) هي شيء أتناوله بالفعل ، وآمل أن يتم إصلاحه قريبًا. بالنسبة لبقية المناقشة ، لا يستخدم المطورون Github كمنتدى ، بعض التذاكر تنتقل إلى ذلك ، التذكرة السابقة التي تم إغلاقها والتي تحتوي أيضًا على سلسلة طويلة تم تجاهلها حتى وقت قريب ، في الغالب بسبب تصفية المطورين للمشكلات المغلقة و نتوقع مناقشات في IRC القائمة البريدية أو قضايا جديدة.

آمل أن يعالج هذا جميع القضايا الرئيسية ، كما هو الحال دائمًا نحن منفتحون للمناقشة ، فلا تتردد في التواصل مع ML أو IRC ، نحن فقط نتجنب استخدام github لأنه ليس مكانًا جيدًا لمثل هذه الأشياء.

شكرا جزيلا للتوضيح.

نقدر لك الوقت الذي تستغرقه في التوضيح على الرغم من أنه كان من الأسهل بكثير التوقف عن دعم تدوين النقاط وإيقاف هذا الدعم على مدار عدة إصدارات. يستخدم عدد أقل من الأشخاص ذلك مقابل عدد الأشخاص الذين لديهم أحرف غير صالحة في أسماء مجموعاتهم. سي لا في

skyscooby المشكلة هي أنه ليس أنسيبل يفعل ذلك ، إنه جينجا.

فقط لقول هذا مرة واحدة ، من الواضح أنك ستكون دائمًا قادرًا على استخدام الدُش في أسماء المجموعة أيضًا النقاط والأحرف الأخرى التي تُعتبر الآن "غير صالحة" ، ولكن ليس افتراضيًا.

حسنًا ، من الجيد معرفة ذلك ، شكرًا للتوضيح. ومع ذلك ، فإن تجربة المستخدم تحتاج حقًا إلى التحسين. لديك "لعنة المعرفة". فقط حاول أن تتخيل نفسك في مكان المستخدم الذي يرى هذا:

[DEPRECATION WARNING]: تم تعيين إعدادات TRANSFORM_INVALID_GROUP_CHARS للسماح بالأحرف السيئة في أسماء المجموعات افتراضيًا ، وسيتغير هذا ، ولكن لا يزال
شكلي للمستخدم عند الإهمال. ستتم إزالة هذه الميزة في الإصدار 2.10. يمكن تعطيل تحذيرات الإيقاف عن طريق تعيين devecation_warnings = False in ansible.cfg.
[تحذير]: تم العثور على أحرف غير صالحة في أسماء المجموعات ولكن لم يتم استبدالها ، استخدم -vvvv لمشاهدة التفاصيل

هذا هو طريق طويل جدا من

[DEPRECATION WARNING] يحتوي اسم المجموعة "my-server" على "-" ، والذي سيصبح غير صالح افتراضيًا من Ansible 2.11. اضبط force_valid_group_names في ansible.cfg أو متغير البيئة ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS على "ignore" لمنع ذلك. راجع https://docs.ansible.com/something لمزيد من المعلومات.

... وهو ما كنت أرغب حقًا في رؤيته كمستخدم. كان سيوفر لي أكثر من ساعة. الآن اضرب في ذلك في عدد الأشخاص الذين لديهم أو سيواجهون هذه المشكلة.

لا يعد وجود الشرط والنقاط غير صالح في أسماء المجموعات أمرًا افتراضيًا معقولاً. سيضعها الأشخاص دائمًا في أسماء مجموعاتهم. إن مطالبتهم بتعيين متغير آخر في ملف التكوين لتمكين السلوك المعقول هو أمر لا يمكن الدفاع عنه بواسطة IMHO.

شكرا bcoca لتعليقك أعلاه. إنه محل تقدير كبير.

على الرغم من أنني لست سعيدًا بالقرار ، إلا أنني أفهم أنه تم إجراء مناقشة واتخاذ قرار. إذا كان القرار لا يزال مفتوحًا للنقاش ، فيجب أن يستمر في قائمة mailling أو على موقع irc ولكن قد لا يتم التقاط هذه المشكلة.

بالنسبة لموضوع هذه المشكلة ، أود أن أجد المعلومات التالية في الوثائق الرسمية وأدلة النقل ، لأكون على علم بهذا التغيير.

• ما هي أسماء المجموعات الصالحة بشكل افتراضي؟
• ما الذي يجب فعله للاستمرار في استخدام أسماء المجموعات بما في ذلك الشرط والواصلات والنقاط والنقطتين؟

لأننا نستخدم الشرطات في جميع أسماء المجموعات والمضيفين لدينا ولن نغير ذلك. لذلك يجب علي الاشتراك وتغيير ansible.cfg كل مرة أقوم فيها بإعداد تثبيت / بيئة جديدة. هذا أمر مؤسف بالنسبة لي ولكن لا بد لي من التعامل معه بطريقة ما. أقل ما أتوقعه هو أن يتم توثيق ذلك وفقًا لذلك.

مواصلة مناقشة ما إذا كان هذا التغيير هو الحكمة أم لا، فتحت موضوع في مجموعة التنمية Ansible.

تحياتي الحارة،
تروند

أود أن أشكر جميع المساهمين في هذا الموضوع. بناءً على ما قرأته هنا ، قررت كتابة منشور مدونة https://docs.sbarnea.com/ansible/naming-hosts-and-groups - آمل أن يلخص ما يحتاج المستخدمون إلى القيام به.

@ loop-evgeny أوافق على أننا كفريق أساسي لدينا "لعنة المعرفة" وهي تمنعنا من إنشاء مستندات وأخطاء مفيدة للجميع. نعتمد أيضًا بشكل كامل على المجتمع لمساعدتنا في تشكيل غير مرغوب فيه وجعله بسيطًا لأكبر عدد ممكن من المستخدمين ، لذلك عندما يكون لدى الأشخاص توصيات بشأن تحسين مستنداتنا ورسائل الخطأ / التحذير الخاصة بنا ، أشجعهم دائمًا على مساعدتنا عن طريق إرسال طلب سحب. الرسالة التي أشرت إليها محفوظة في الملف التالي وسنكون ممتنين للغاية إذا أرسلتم إلينا PR بالتغيير المقترح ...

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

jctanner عادةً يسعدني إرسال العلاقات العامة لتحسين برنامج مجاني ومفيد أستخدمه. ومع ذلك ، فإن الموقف العام لمطوري Ansible تجاه قابلية الاستخدام ، وحرصهم على إغلاق مشكلات "العمل على النحو المنشود" التي أعتبرها أخطاء واضحة (حتى لو كانت أخطاء التصميم) وحقيقة أن Ansible لديها حاليًا 2025 (أي ألفي !) العلاقات العامة المفتوحة تمنحني القليل من الثقة في أن عملي لن يذهب هباءً. إذا كنت تريد حقًا "الاعتماد على المجتمع" ، كما تقول ، فهناك حاجة إلى تغيير ثقافي جوهري IMHO.

حسنًا .. تلك الفرصة صدمتني أيضًا.

لسوء الحظ ، نستخدم أسماء الشبكات كأسماء مجموعات ولا يمكن تغييرها بسهولة. أرغب في إلغاء الاشتراك في الصيغة النقطية sugar لأسماء المجموعات لأن هذا ليس شيئًا استخدمته على الإطلاق (على الرغم من أنني استخدمه مع متغيرات أخرى).

يفضل استخدام ansible-playbook whatever.yaml -l some.network.to.use في المستقبل. سيؤدي استخدام أي اسم آخر بخلاف الشبكة كاسم مجموعة إلى تقليل حالة الاستخدام بشكل كبير.

أهلا،
أنا في حيرة من أمري في الوقت الحالي. هل يمكن أن يخبرني أحدهم بما يجب أن أقوم بتعيينه في ansible.cfg للسماح بحروف غير صالحة في أسماء المجموعات في المستقبل ، من فضلك؟

force_valid_group_names = ignore

ما هو الإصدار المستقبلي من إعادة التدوير غير القابل للتصرف لهذه المشكلات؟ هل سيرفض 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 لأنني أقف بقوة على جانب الشرطات> الشرطات السفلية. مجرد إجراء بحث سريع على

حتى لو لم يكن الأمر كذلك ، فإن حقيقة أنني أرى الشرطات المستخدمة لأشياء مثل تسميات الخادم والمجموعات في البرية كثيرًا أكثر من الشرطات السفلية تعني أن هذا سيكون شيئًا آخر يجب أن أتأكد من إضافته إلى كل ما لدي وملفات عملائي 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 بعد الآن خارج منطقة الجزاء.

لا يمكن أن تتضمن أسماء المضيف شرطة سفلية ، لذلك في عالم عاقل ، لن يتم إجبار اسم المضيف على ذلك. هذا يعني أن قوائم الجرد الخاصة بنا ستبدو الآن غير متسقة تمامًا ، مع أسماء المضيف التي لا يمكن أن تحتوي على شرطات سفلية ، والمجموعات التي لا يمكن أن تحتوي على واصلات.

من فضلك ، فقط لا تقم بتبديل الافتراضي.

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

أهلا،
أنا أتفق تماما مع جيف هنا .

ولكن كما ذكر bcoca أعلاه ، فإن معظم المطورين لا ينظرون إلى هذه المناقشات هنا بشكل منتظم وقد لا تكون هذه المشكلة هي المكان المناسب لمناقشة التغيير لأنه يتعلق بالتوثيق الصحيح.

للمناقشة يرجى الانضمام إلى الموضوع هل تغيير الإعداد الافتراضي لـ TRANSFORM_INVALID_GROUP_CHARS فكرة جيدة؟ في مجموعات Google.

النقاط العظيمة جيف.

ليس من الممتع أن يكون لديك افتراضي يجب تجاوزه دائمًا تقريبًا لجعل البرنامج يعمل ، ولكن يبدو أنه اعتبارًا من Ansible 2.11 ، سيكون هذا هو الحال.

هذه هي النتيجة الكبيرة بالنسبة لي من كل هذه المناقشات. أفهم المشكلة التي يجب حلها ، لكن يبدو أن الحل هو عكس ما هو مطلوب. إنه يجعل الأمور أسهل بالنسبة للدعم ولكنه صعب على المستخدمين - وهذا حل عكسي.

إذا كان السبب كله هو أن بعض المستخدمين غير المعتادين على Jinja2 و Python لا يدركون شيئًا ما. مع وجود بعض الشرطات غير صالحة ، سأجادل أنه من الأفضل تعليمهم "إذا كانت هناك شرطات ، فيجب عليك استخدام تدوين القوس للوصول إلى ديكت ، على سبيل المثال شيء ما ["مع بعض الشرطات"]. يمكنك حتى خلط الاثنين إذا لزم الأمر.

هذا هو الحل الأفضل ، وليس كسر الأشياء التي تم استخدامها لسنوات.

تعليق رائع من geerlingguy - بقعة على!

أود أن أضيف ذلك كمستخدم لـ Ansible ، فلماذا يجب أن أعرف ما هو بناء جملة Python الصحيح؟ بعد أن استخدمت Ansible لفترة طويلة الآن ، أدركت أن Ansible (ووحداته النمطية) مكتوبة بلغة Python ، ولكن لماذا يجب أن أهتم بذلك؟ كشف هذه الحقيقة للمستخدم النهائي هو مجرد تصميم سيء.

مشابه للسماح فقط لـ JavaScript / Ruby / .NET / أيًا كان تدوينًا صالحًا لأشياء مثل أسماء المستخدمين في تطبيق ويب. لماذا يهتم المستخدم النهائي باللغة التي تمت كتابة التطبيق بها؟

بالإضافة إلى ذلك ، إدخال التغييرات العاجلة موضوع صعب ، أحاول تجنب ذلك إن أمكن. إذا اضطررت إلى إجراء تغيير ، فأنا عادةً ما أترك السلوك القديم الحالي باعتباره السلوك الافتراضي ، وأسمح للأشخاص بالاشتراك في السلوك الجديد. لماذا لم يتم ذلك هنا؟ لماذا يتعين علي إما تغيير التكوين الخاص بي ، أو تغيير مخزوني بالكامل؟ لماذا لا العكس؟

إذا كان النظام يتطلب رموزًا متوافقة تمامًا داخليًا ، فيجب على النظام إنشاء الرموز المميزة داخليًا وإنشاء جدول بحث يربط الرموز المميزة الداخلية ببيانات المستخدم. وبهذه الطريقة ، يمكن لـ Ansible تغيير قواعد الرمز الخاص بها حسب الحاجة وتحد من التأثير على المستخدمين. يجب أن يكون المستخدمون قادرين على تسمية مخزونهم وأدوارهم وما إلى ذلك كما يراهون أو يراه عملاؤهم مناسبًا.

يبدو لي أن هذا التغيير قد يكون له تأثير معاكس له (لتقليل استعلامات الدعم):

الآن لا يوجد محدد مدعوم (افتراضيًا) بواسطة أسماء المضيف (والتي يجب أن تكون قابلة للحل بنظام DNS ، أي لا تحتوي على شرطات سفلية) وأسماء المجموعة (التي يجب ألا تحتوي على شرطات).

بالتأكيد يجب أن تكون حرة في تسمية أي مضيفين

El mié. ، قبل 14. 2019 الساعة 16:16 ، كريستيان بوينتنر [email protected]
escribió:

إذا فهمت هذا
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٪}

وهو بالطبع جيد تمامًا.

في محاولة لتسهيل الأمور على المستخدمين ، يبدو أن أنسبل دائمًا
أجرى بعض التطهير لأسماء المجموعات. هذا يعني أنه كان (وحتى 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=AA5N2CJCIELW7JWHC6OJ35DQEQHSPA5CNFSM4HPRGLKKYY3PNVWWK3TUL52HS4DFVREXG43VMVB37
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AA5N2CIVT5PLD2QCAGGBK6LQEQHSPANCNFSM4HPRGLKA
.

هذا حقًا قرار خاطئ من وجهة نظري الصادقة. ولسبب خاطئ. تقليل عدد طلبات الدعم حقاً؟

يجب ألا يفرض Ansible ، كأداة ، تفاصيل لغة محددة للمستخدم النهائي. أنا بالفعل منزعج للغاية من فرض Terraform لي كل ذلك Golang أسفل الحلق ، والآن يحدث الشيء نفسه هنا مع Ansible والأسلوب "Pythonic". لا تفهموني بشكل خاطئ ، فأنا أعمل جيدًا مع كل من Go و Python ، ولكن عندما يتعلق الأمر بالبنية التحتية كرمز ، فلماذا أهتم؟ وماذا حدث مع الوعد بجعل YAML تملي شكل قاعدة الكود المطلوب إدارتها؟ "البنية التحتية كبيانات ، يمكنك قراءتها وتشغيلها" ، سمعت ذلك مرات عديدة ... وبقدر ما أعرف ، لا تهتم YAML على الإطلاق بكل من الشرطات والشرطات السفلية.

راجع للشغل ، هناك الكثير من الأشياء التي لا تدعم الخطوط السفلية. أسماء المضيفين ومناطق AWS والمعرفات لكل شيء حرفيًا ، فقط لذكر بعض الأشياء المهمة حقًا. حظًا سعيدًا في الحفاظ على جميع الاستثناءات حيث لا يُفترض أن يحدث التحول ...

للأشخاص الذين يأتون إلى هنا يبحثون فقط عن حل سريع حول كيفية التخلص من ذلك ، ما عليك سوى إضافة السطر force_valid_group_names = ignore إلى ansible.cfg وكن سعيدًا.

ما أفهمه هو أنه لا يمكنك استخدام التدوين النقطي للمتغيرات ذات المسافات على أي حال ، وعلى الرغم من أنني لا أقوم أبدًا بإنشاء متغيرات بمسافات ، فهناك للأسف الكثير من البائعين الذين يقومون بإرجاع مفاتيح القاموس بمسافات من خلال استجابات json API. يبدو أن الخيار المعقول بالنسبة لي هو التبديل إلى تدوين القوسين المربعة. نأمل ألا يتسبب تعيين force_valid_group_names على التجاهل في حدوث آثار سيئة في المستقبل ، ومن يعرف ما هو مخطط له في المستقبل بهذا التغيير.

هذا قرار مروع للغاية خاصة عندما يتعلق الأمر بالعمل مع قوائم جرد ديناميكية كما هو الحال مع Openstack (و AWS).
غالبًا ما يتم إرجاع أسماء المثيلات ومفاتيح البيانات الوصفية التي تحتوي على "أحرف محظورة" كعناصر مخزون و / أو متغيرات مجموعة من السحابة الأساسية. سيؤدي هذا إلى جعل الحياة جحيمة بالنسبة للكثير من مسؤولي Openstack (و AWS) الذين يحاولون إدارة أساطيلهم باستخدام العلامات الوصفية و / أو معرف المثيل مثل:
مثيل-8ca09c33-f255-440f-9544-b0ab318c79d9
meta-os_ubuntu

يجب على مطوري Ansible أن geerlingguy على محمل الجد. إنه أحد أكبر المساهمين في Ansible Galaxy ويستهلك الكثير من الأشخاص أدواره. أعتقد أن هذا التغيير سيء حقًا للأشخاص الذين لديهم آلاف من المضيفين بأسماء مثل: $env-$role-[0..99] . هل من المفترض أن نعيد تسمية كل شيء لإرضاء أسيادنا Ansible؟

ssbarnea لسبب واحد ، نحن نقوم بالدفع للسماح فقط بأسماء المتغيرات ، ومفاتيح أخرى مماثلة ، والتي تعد معرّفات بيثون صالحة. لتوضيح المزيد حول أسماء المجموعات ، يتسبب ذلك في مشكلة للمستخدمين الذين يحاولون استخدام "بناء الجملة" مثل groups.foo-group ، والذي لا يفعل ما يتوقعه المستخدم. لقد تسبب عدد المشكلات وطلبات الدعم الناتجة عن مشكلات صغيرة مثل هذه في السير في مسار لأسماء الحماية الآمنة لضمان عدم حدوث مثل هذه المشكلات.

بالنسبة لأولئك الذين يريدون الاحتفاظ بما نعتبره أحرفًا غير صالحة ، يمكنهم إلغاء الاشتراك في هذه الوظيفة.

ما المدة التي سيتم السماح للمستخدمين فيها بالانسحاب من هذا السلوك؟ هل سيكون هناك خيار تكوين دائم لتعطيل هذا السلوك في جميع الإصدارات غير الصالحة للمضي قدمًا ، أم أنه سيتم دعمه حتى 2.11 فقط؟ سأكون سعيدًا بتشغيل الخيار افتراضيًا ، طالما لدي دائمًا خيار إيقاف تشغيله.

إذا أصبح هذا قيدًا صارمًا في الإصدار 2.11+ ، فمن المحتمل أن تجد نفسك تفقد عملاء ملزمين بقيود مؤسستهم (ليس كل المستخدمين المخلصين لديهم القدرة على إملاء اصطلاحات التسمية التي تستخدمها شركتهم). يبدو أن هذا التغيير سيشكل أيضًا تحديًا كبيرًا لأولئك الذين يستخدمون غير قادر على إدارة البنية التحتية السحابية ، حيث تميل الشرطات إلى الاستخدام المكثف.

فقط لتذكير أولئك الذين لم يقرأوا الموضوع بالكامل هنا. يوجد أيضًا موضوع في قائمة التطوير: https://groups.google.com/forum/#!topic/ansible -devel / bjAcM9ferIw

IMHO كان هذا التغيير خيارًا سيئًا حقًا. التغييرات في بناء جملة فك التشفير في الإصدارات الثانوية تمنعنا من توسيع استخدام Ansible في بيئتنا. لأنني لن أتمكن من تحديث Ansible عندما يكسر قواعد اللعبة للمستخدمين.

ولكن كما ذكر bcoca أعلاه ، فإن معظم المطورين لا ينظرون إلى هذه المناقشات هنا بشكل منتظم وقد لا تكون هذه المشكلة هي المكان المناسب لمناقشة التغيير لأنه يتعلق بالتوثيق الصحيح.

Tronde : قد يجادل المرء بأنه تتم استشارة المساهمين والعملاء قبل كتابة القصص لفهم التأثير وجمع التعليقات جيدًا قبل أن يقوم شخص ما بترميز الحل. كما ذكر العديد هنا ، هذا منتج فشل رأيناه أكثر من مرة.

كمثال على الموقف ، يصف andyfeller هذا التغيير:

لدينا مشكلة مع هذا على موقعنا.

نحن نستخدم Red Hat Identity Manager كمخزون خارجي ، ولا نتحكم فيه ، فهو يحتوي على العديد من المجموعات المضيفة مع شرطات بدلاً من الشرطات السفلية. لن يتغير هذا (بسبب كل الأشياء الأخرى الموجودة باستخدام تلك الأسماء).

لذلك نحن بحاجة:

• لتكوين أنسبل للحفاظ على السلوك الحالي
• كتم صوت تحذير الإيقاف
• افعل هذا مع سطر الأوامر Ansible و Ansible Tower

تم تحديد FYI PR https://github.com/ansible/ansible/pull/66650 (من فضلك لا توجد مذراة هناك) لـ 2.10 (اعتبارًا من اللحظة الحالية) ، مما يعني أن أي شخص يرى هذا التحذير حاليًا سيفعل (بمجرد الترقية إلى 2.10 ، مرة أخرى على افتراض أن العلاقات العامة مدمجة) ابدأ في مواجهة إخفاقات قواعد اللعبة بدلاً من ذلك (حتى قاموا بتعيين force_valid_group_names = ignore في ansible.cfg ).

مجرد نشر للرؤية. ما زلت وراء تأكيدي السابق بأن هذا يعد افتراضيًا معاديًا للمستخدم ، حيث لا يزال هناك العديد من البرامج النصية للمخزون الديناميكي (جزء من Ansible نفسه أو تم نقله الآن إلى مجموعات "official-ish") التي تنشئ أسماء مجموعات مع شرطات أو أحرف DNS صالحة أخرى.

عمليًا ، سيتعين على أي شخص يستخدم Ansible مع AWS تجاوز الإعداد الافتراضي.

geerlingguy هل هذا حق العلاقات العامة #؟ يبدو أن هذا يشير إلى هذه المشكلة.

لمعلوماتك تمت مناقشة هذا في اجتماع أساسي هنا ، بدءًا من 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-idifier ، ولكن هذا ليس حقًا سهل الاستخدام أو قابل للقراءة للأشخاص الذين ليس لديهم خلفيات في علوم الكمبيوتر.

سبب السؤال هو أنني لست متأكدًا مما إذا كان قد تم التعامل مع الشكوى الأولية الفعلية. هناك فقط تحذير من وجود خطأ ما ، ولكن الأمر يتطلب الكثير من البحث لمعرفة ما بالضبط وكيف - إذا كان يرغب أو يستطيع - في الواقع اختيار اسم مجموعة صالح. أتوقع على الأقل وجود "اسم المجموعة foo-bar يحتوي على أحرف غير صالحة ( - ). يجب أن تكون أسماء المجموعات الصالحة معرّفات Python صالحة (انظر https://docs.python.org/??? لمزيد من المعلومات)" رسالة ، وليس فقط "هناك أحرف سيئة ، تحقق مرة أخرى باستخدام -vvvv لمعرفة أيها بالفعل!". من الناحية المثالية ، سيشير هذا أيضًا إلى أنه يمكن تعطيل هذا ، ولكن قد يؤدي إلى مشاكل أخرى غير متوقعة (مثل جعل من الصعب حقًا على Ansible التمييز بين المجموعات foo-bar ، foo.bar و foo_bar ).

إنها حاليًا عبارة عن رسالة "لقد فعلت شيئًا خاطئًا ، أصلحه" بدون طريقة واضحة توضح كيفية المتابعة والتي ربما تكون قد ساهمت أيضًا في الاستجابة القوية هنا.

geerlingguy كتب في تعليق 56930 :

(حتى يتم تعيين force_valid_group_names = false في ansible.cfg)

لم تذكر الوثائق "خطأ" كقيمة صالحة لهذا المفتاح. لقد قمت بتعيين القيمة على "تجاهل" وهو ما يجب أن يؤدي إلى الحيلة. ولكن هل كلمة "خطأ" كلمة رئيسية غير صالحة أم أنها صحيحة والتوثيق غير مكتمل هنا؟

bcoca في تعليق سابق:

فقط لقول هذا مرة واحدة ، من الواضح أنك ستكون دائمًا قادرًا على استخدام الدُش في أسماء المجموعة أيضًا النقاط والأحرف الأخرى التي تُعتبر الآن "غير صالحة" ، ولكن ليس افتراضيًا. هذا "الافتراضي" هو ما يتم إهماله ، سيكون الإعداد الافتراضي "آمنًا" في 2.11 ، ولكن سيكون لديك دائمًا خيار "الاشتراك" في السلوك القديم.

لقد ذكرت مرارًا وتكرارًا أنه يمكن الحفاظ على السلوك الحالي ، ولكن ما هي إعدادات ansible.cfg الدقيقة المطلوبة للقيام بهذا _now_ وسحق تحذير الإهمال.

لقد حاولت كما كتب geerlingguy في التعليق 56930:

(حتى يتم تعيين force_valid_group_names = false في ansible.cfg)

مما يتسبب في فشل كتيبات التشغيل الخاصة بي عندما لا يتمكن من العثور على مضيفين أو مجموعات بها واصلات (إنهم قادمون من مكون إضافي للمخزون كتبناه راجع للشغل ، هل يجب أن تقوم الأطروحات بإجراء التحويل أيضًا ، أو يتم ذلك عندما يستوعب Ansible المخزون من البرنامج المساعد؟)

لقد حاولت كما كتب geerlingguy في التعليق 56930:

(حتى يتم تعيين force_valid_group_names = false في ansible.cfg)

مما يتسبب في فشل كتيبات التشغيل الخاصة بي عندما لا يتمكن من العثور على مضيفين أو مجموعات بها واصلات (إنهم قادمون من مكون إضافي للمخزون كتبناه راجع للشغل ، هل يجب أن تقوم الأطروحات بإجراء التحويل أيضًا ، أو يتم ذلك عندما يستوعب Ansible المخزون من البرنامج المساعد؟)

تم ذكر ذلك في عدة تعليقات وهو موجود في الوثائق . يجب ألا تستخدم أبدًا أو تتجاهل .

فهل من المفترض ألا نستخدم البرنامج النصي الديناميكي للمخزون 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". لا ، "هذا المشروع ليس ديمقراطية".

لأكون صريحًا ، هذا خطأ مع المصدر المفتوح - إذا أدى إلى طريقة غير شائعة - يمكن للناس تفرعها ، هل يمكن تشعبها؟

أستطيع أن أرى قبول العلاقات العامة غير المرغوبة ببطء شديد. من الواضح أن التصحيحات تبدو ضرورية وتغيير بسيط ، لكنها لا تدخل أبدًا. لحسن الحظ ، فإن ميزة ansible نفسها مرنة للسماح للأشخاص باستخدام المكونات الإضافية المخصصة ولكن يبدو أنها لا معنى لها ستجعل نفسي أقل في المساهمات - أو حتى أكثر صعوبة في القيام بذلك.

الشعور بالحزن قليلا حقا ...

@ sunshine69 أشعر بألمك. لكن هذا نقاش يجب أن يتم على IRC أو Google Group for Ansible Development.

هذه القضية ليست المكان المناسب لها. لأن قلة من الناس تقرأ هنا.

@ sunshine69 أشعر بألمك. لكن هذا نقاش يجب أن يتم على IRC أو Google Group for Ansible Development.

هذه القضية ليست المكان المناسب لها. لأن قلة من الناس تقرأ هنا.

في حين أن المناقشة قد تكون أكثر إنتاجية في تلك القنوات الأخرى ، فإن الشفافية موضع تقدير للأشخاص الذين يتابعون هذه المشكلة على وجه التحديد. IRC ليس المفضل لدى الجميع بعد كل شيء.

لمعلوماتك: تم دمج إزالة الإهمال لـ TRANSFORM_INVALID_GROUP_CHARS بالأمس للتو. توجد ملفات PRs 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 مرة = 10.6 مللي ثانية

[ webadmin @ vlodjumpts00 ~] $

-bash: mirrorlist.centos.org: الأمر غير موجود

أريد استخدام هذا لمنظمتنا .. إذا قمت بتشغيل الأمر "ansible all -m ping". تواجه الخطأ ، فيما يلي التفاصيل:

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

التغيير ، ولكن لا يزال قابلاً للتكوين بواسطة المستخدم عند الإيقاف. ستتم إزالة هذه الميزة في الإصدار 2.10. يمكن أن تكون تحذيرات الإيقاف

تم تعطيله عن طريق تعيين devecation_warnings = False in 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

}

المضيف المحلي | نجاح => {

"ansible_facts": {

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

},

"changed": false,

"ping": "pong"

}

الرجاء مساعدتي ... ما أحتاجه للقيام بذلك. في الواقع ، ليس لدينا ملف الأمم المتحدة / الأشخاص ذوي الإعاقة للمضيفين لتوصيل الجهاز المضيف ..

المضيف المحلي ansible_connection = محلي

[RTE3VFO]

RTE3VFOAdmin ansible_host = vlddwblasts001.test.intranet

RTE3VFOM مدار 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

RTE3RESAM المُدارة 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

RTE3EASEM المُدار 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 Dec 8 2019 ansible.cfg.rpmnew

-rw ------- 1 webadmin webadmin 213 يوليو 3 2017 easeasr-rte2-easy.yml

-rwxr-xr-x 1 webadmin webadmin 1034 19 سبتمبر 09:16 easy-hosts

-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 ديسمبر 8 2019 أدوار

-rwxr-xr-x 1 webadmin webadmin 7321 2 نوفمبر 2017 servmix_hosts

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

-rw ------- 1 webadmin webadmin 122 سبتمبر 19 10:54 vars.yaml

نحن لسنا متصلين مباشرة بالمضيف ... قم بتسجيل الدخول إلى خادم الانتقال الخاص بنا ومن مضيف ssh ...

خادم الانتقال هو منفذ "vmdcltctws217" باستخدام = 22 ، نوع الاتصال = ssh

ثم ادخل مع الأمم المتحدة / الأشخاص ذوي الإعاقة

بعد ذلك فعلنا sudo للاتصال بالخادم المضيف ..

sudo su - easesqa

ثم خادم ssh المضيف مثل ..

vlddwblasts001.test.intranet

ثم نقوم بتشغيل الأمر start / stop من هنا ..

الرجاء مساعدتي ، ما الذي يمكنني القيام به؟