विवरण में पहचानी गई फ़ाइलें:

• lib/ansible/मॉड्यूल/system/group.py

अगर ये फ़ाइलें गलत हैं, तो कृपया विवरण के component name अनुभाग को अपडेट करें या !component bot कमांड का उपयोग करें।

बॉट सहायता के लिए यहां क्लिक करें

सीसी @sfromm
बॉट सहायता के लिए यहां क्लिक करें

मुझे यह चेतावनी मिलनी शुरू हुई लेकिन पोर्टिंग गाइड में कोई संदर्भ नहीं मिला और कोई संदर्भ नहीं मिला कि कैसे या क्या ठीक किया जाए।

मेरी अधिकांश चेतावनियां ec2.py से हैं, जहां instance_id ने - (उदाहरण: i-033f62b586143dff7 ) और क्षेत्रों (उदाहरण: eu-central-1c ) का उपयोग किया है, इसलिए हमारे पास कोई नहीं है इसके लिए असली फिक्स

अंत में, इसने मेरी कुछ प्लेबुक को तोड़ दिया, जहां मैंने when: ansible_hostname in groups['varnish'] और ansible_hostname varnish-eu-central-1c-001 ।
अतीत में यह ठीक काम करता था, अब मुझे inventory_hostname करने के लिए varnish_eu_central_1c_001 प्राप्त करने और groups['varnish'] बनाम एक मैच प्राप्त करने की आवश्यकता है

इसलिए इसे पोर्टिंग गाइड में कम से कम और तत्काल एक चेतावनी की आवश्यकता है कि inventory_hostname और groups[] अलग-अलग डेटा लौटा सकते हैं

समूह के नामों से डैश हटाने के पीछे क्या तर्क था? मैं वास्तव में इसके लिए अच्छे कारण खोजने के लिए संघर्ष करता हूं, खासकर क्योंकि इसके लिए बहुत सारे कोड रिफैक्टरिंग की आवश्यकता होगी।

@ssbarnea एक बात के लिए, हम केवल चर नामों और अन्य समान कुंजियों को अनुमति देने के लिए एक धक्का दे रहे हैं, जो कि मान्य अजगर पहचानकर्ता हैं। समूह नामों के बारे में थोड़ा और समझाने के लिए, यह "डॉट सिंटैक्स" जैसे 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] आईएनआई-अनुभाग में जोड़ें ansible.cfg ।

चेतावनी को ट्रिगर करने वाले सभी समूहों और अमान्य वर्णों को देखने के लिए (शायद इसलिए आप उन्हें चरण-आउट के लिए लक्षित कर सकते हैं), आप कुछ ऐसा कर सकते हैं जैसे कि सीएलआई नो-ऑप:

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 ।
(मुझे आशा है कि मुझे यह सही लगा)

यदि आपको पदावनति चेतावनियां कष्टप्रद लगती हैं, तो आप उसी [defaults] deprecation_warnings = False जोड़कर किसी भी ansible- कमांड या ansible एड-हॉक कमांड के लिए उन्हें स्थायी रूप से अक्षम भी कर सकते हैं। [defaults] ansible.cfg [defaults] अनुभाग, लेकिन मैं इसके खिलाफ अनुशंसा करता हूं (क्योंकि आप महत्वपूर्ण समाचारों को याद कर सकते हैं), और इसके बजाय इनलाइन शेल पर्यावरण चर का उपयोग करें:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

हालांकि, [WARNING] s की इन्वेंट्री पार्सिंग समाप्त नहीं होगी। सभी चेतावनियों को बंद करने के लिए कोई विशिष्ट कॉन्फ़िगरेशन या env var नहीं है (अभी तक?), लेकिन अगर यह वास्तव में आपको परेशान करता है, तो आप सभी stderr को /dev/null भेज सकते हैं (यहां "सर्वोत्तम अभ्यास" चेतावनी डालें):

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

उम्मीद है कि यह किसी की मदद करता है, कहीं।

मुझे केवल बहिष्करण चेतावनी संदेश परेशान करते हैं जब वे माइग्रेशन पथ प्रदान नहीं करते हैं। यह ध्यान में रखते हुए कि स्थान सीमित है और उपचार के लिए अद्यतन की आवश्यकता होने की संभावना है, मुझे टिकटों के लिंक प्रदान करने में बहुत उपयोगी लगेगा जो समाधान, कामकाज, दस्तावेज कर सकते हैं ...

इस तरह का एक दृष्टिकोण अधूरे चेतावनी संदेशों को सुधारने के लिए आवश्यक अतिरिक्त कार्य को बचा सकता है क्योंकि हमें संदेश को अपडेट नहीं करना होगा, इसे कुछ संस्करणों में वापस करना होगा।

पुनश्च. बहिष्करण चेतावनियों को अक्षम करना कुछ ऐसा है जो मैं किसी को भी अनुशंसा नहीं करता, शायद केवल तभी जब कोई परियोजना पहले से ही अपने अंतिम भाग्य का सामना कर रही हो;)

मुझे यह चेतावनी मिलनी शुरू हुई लेकिन पोर्टिंग गाइड में कोई संदर्भ नहीं मिला और कोई संदर्भ नहीं मिला कि कैसे या क्या ठीक किया जाए।

मेरी अधिकांश चेतावनियां ec2.py से हैं, जहां instance_id ने - (उदाहरण: i-033f62b586143dff7 ) और क्षेत्रों (उदाहरण: eu-central-1c ) का उपयोग किया है, इसलिए हमारे पास कोई नहीं है इसके लिए असली फिक्स

अंत में, इसने मेरी कुछ प्लेबुक को तोड़ दिया, जहां मैंने when: ansible_hostname in groups['varnish'] और ansible_hostname varnish-eu-central-1c-001 ।
अतीत में यह ठीक काम करता था, अब मुझे inventory_hostname करने के लिए varnish_eu_central_1c_001 प्राप्त करने और groups['varnish'] बनाम एक मैच प्राप्त करने की आवश्यकता है

इसलिए इसे पोर्टिंग गाइड में कम से कम और तत्काल एक चेतावनी की आवश्यकता है कि inventory_hostname और groups[] अलग-अलग डेटा लौटा सकते हैं

मैं EC2 डायनेमिक इन्वेंट्री स्क्रिप्ट द्वारा उत्पन्न की जा रही चेतावनी के बारे में कथन प्रतिध्वनित करना चाहता हूं। मैंने देखा कि इंस्टेंस_आईडी ( group_by_instance_id = False ) द्वारा ग्रुपिंग होस्ट को अक्षम करने के लिए एक ec2.ini कॉन्फ़िगरेशन सेटिंग है, लेकिन सेटिंग ने मेरे लिए चेतावनी को हल नहीं किया जैसा मैंने अनुमान लगाया था - मैंने सुनिश्चित किया कि मैं स्थानीय इन्वेंट्री कैश को साफ़ कर दिया।

विशेष रूप से ईसी 2 गतिशील सूची के लिए कोई कामकाज?

ये अमान्य वर्ण (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- कमांड या ansible एड-हॉक कमांड के लिए deprecation_warnings = False को उसी [defaults] जोड़कर स्थायी रूप से अक्षम कर सकते हैं। ansible.cfg [defaults] अनुभाग, लेकिन मैं इसके खिलाफ अनुशंसा करता हूं (क्योंकि आप महत्वपूर्ण समाचारों को याद कर सकते हैं), और इसके बजाय इनलाइन शेल पर्यावरण चर का उपयोग करें:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

हालांकि, [WARNING] s की इन्वेंट्री पार्सिंग समाप्त नहीं होगी। सभी चेतावनियों को बंद करने के लिए कोई विशिष्ट कॉन्फ़िगरेशन या env var नहीं है (अभी तक?), लेकिन अगर यह वास्तव में आपको परेशान करता है, तो आप सभी stderr को /dev/null भेज सकते हैं (यहां "सर्वोत्तम अभ्यास" चेतावनी डालें):

गैर-दस्तावेज ignore विकल्प यह कार्यक्षमता प्रदान करता है। डॉक्स पीआर यहाँ: https://github.com/ansible/ansible/pull/57318

2.8.2 से शुरू होकर, यदि आप स्पष्ट रूप से कोई भी विकल्प सेट करते हैं, तो यह बहिष्करण चेतावनी रद्द कर दी जाएगी।

इस प्रकार के निर्णयों पर उत्तरदायी देव टीम कहाँ चर्चा करती है? हम उपयोगकर्ताओं के लिए इसका कारण समझना बहुत कठिन है। यदि यह व्यावहारिक तर्क के बजाय शुद्ध "पायथन शैली" तर्क है, तो यह पुनर्विचार के लायक हो सकता है? यदि समूह के नामों में एक पानी का छींटा भविष्य के रिलीज में चीजों को तोड़ देता है, तो यह कार्यान्वयन के साथ एक समस्या हो सकती है, समूह के नामकरण से अधिक?

मेरे लिए, यह एक कॉस्मेटिक बदलाव की तरह लगता है, उस चीज़ की तुलना में जिसे ठीक से सोचा गया है।

एक समूह का नाम एक चर नाम नहीं है, यह इस तरह की सामग्री है। एक हाइफ़न/डैश सिर्फ एक चरित्र है, जो नामकरण सम्मेलन में जानकारी को समूहबद्ध करने का एक बेहद लोकप्रिय तरीका भी होता है। विस्मयादिबोधक बिंदु या तारे की तुलना में, इसका एक सीमा खंड में विशेष अर्थ नहीं है।

इस मुद्दे को कम करने की लागत बहुत अधिक है, यह देखते हुए कि हजारों साइटों को न केवल सूची में समूह के नाम बदलने होंगे, बल्कि अपनी सभी प्लेबुक और घरेलू भूमिकाओं के माध्यम से भी जाना होगा, और उन सभी का फिर से परीक्षण करना होगा।

अगर "किसानों" के पास अपनी आवाज सुनाने का कोई तरीका है, तो मैं अपनी राय में चिप लगाना चाहता हूं और यह समझने की कोशिश करता हूं कि यह विचार कैसे आया।

मुझे यह समझाया गया है कि परिवर्तन ansible करने के लिए बनाया गया था, क्योंकि उन में इस तरह के प्रयोग करने की कोशिश के रूप में गलतियाँ की आए हैं groups.group-name बजाय groups['group-name'] । एआईयूआई, यह विशुद्ध रूप से समर्थन मुद्दों को कम करने के उद्देश्य से एक बदलाव है। (मैं व्यक्तिगत रूप से बदलाव का विरोध करता हूं।)

पुराना व्यवहार नहीं चलेगा; यह स्पष्ट रूप से पुराने व्यवहार को चुने बिना अनुपलब्ध हो जाएगा।

सुन कर दुख हुआ।

मेरा उपयोग मामला यह है कि मैं एक वैग्रांट फ़ाइल में "ansible-inventory" कमांड को एम्बेड कर रहा हूं, इस तरह से जहां चीजों को ansible.cfg में रखना असभ्य है, और यह ओवरराइड करने में सक्षम होने में मदद करेगा। एक कमांड लाइन विकल्प के रूप में व्यवहार (पर्यावरण चर नहीं)।

आमतौर पर इस तरह के बदलाव अच्छे इरादों के कारण होते हैं, लेकिन हो सकता है कि यह हमेशा उस परिणाम की ओर न ले जाए जो किसी के मन में होता है।

इस परिवर्तन के साथ मेरी समस्या यह है कि समूह के नाम अब कुछ हद तक "विशेष" हो गए हैं - मेजबान नामों में डैश की अनुमति है, लेकिन समूह नामों में नहीं, जो hosts: अनुभाग में एक प्लेबुक की शुरुआत में इसे थोड़ा अजीब बनाता है। मैं मेजबान और/या समूह के नाम लिख सकता था।

क्या @sivel द्वारा दिया गया स्पष्टीकरण वास्तव में इस बदलाव के पीछे का एकमात्र कारण है? फिर hosvars['foo-host'] बारे में क्या? मुझे आशा है कि कोई भी इन्वेंट्री होस्ट नामों में भी डैश को अमान्य वर्ण बनाने पर विचार नहीं कर रहा है ...
hostvars अलावा ऐसे कई अन्य उदाहरण हैं जहां "डॉट-नोटेशन" का उपयोग नहीं किया जा सकता है, इसलिए यह जानने की जरूरत है कि कौन सा फॉर्म कब उपयोग करना है। मुझे लगता है कि यह समूह नामों को अलग करने के लिए मनमाना है।

जबकि डॉट-नोटेशन तर्क कुछ हद तक वैध बहाना है, मुझे नहीं लगता कि यह दस्तावेज़ीकरण में सुधार किए बिना आपके समर्थन मुद्दों को ठीक कर रहा है। यदि आपके उपयोगकर्ता कुछ बेवकूफी कर रहे हैं, तो आपका दस्तावेज़ीकरण पर्याप्त नहीं है। सभी देव बहुत सारे उपयोगकर्ताओं को अलग-थलग करने में सफल रहे हैं। समूह नाम जिन्हें मैं मनमाना स्ट्रिंग मान के रूप में देखता हूं। अल्फ़ान्यूमेरिक और अंडरस्कोर को ईमानदारी से प्रतिबंधित करना कुछ हद तक एक दर्द है, खासकर जब होस्टनाम RFC डैश, पीरियड्स आदि की अनुमति देता है ... यदि अंडरस्कोर नामकरण सम्मेलनों के लिए वास्तविक मानक थे तो मुझे नहीं लगता कि यह एक मुद्दा होगा। हाइफ़न का व्यापक रूप से डिस्क्रिप्टर स्ट्रिंग्स के लिए उपयोग किया जाता है। यदि आप अपने समर्थन की मात्रा को कम करना चाहते हैं तो डॉट नोटेशन समस्या को दूसरी दिशा से संबोधित करने का प्रयास करें; एक सत्यापन स्क्रिप्ट बनाएं जो आपकी सहायता टीम सर्वोत्तम अभ्यास मुद्दों के लिए वह जांच प्रदान कर सकती है और उदाहरण के रूप में चेतावनी या मार्गदर्शन प्रदान करती है। डॉट-नोटेशन चेतावनी के बारे में अपने दस्तावेज़ों को बड़ा, बोल्ड, लाल, चमकता, जो भी हो, अपडेट करें... यदि आपका दस्तावेज़ पहले से ही समस्या को कवर करता है तो ऐसे समर्थन मामलों में 1 मिनट की कॉल आती है। फ़ोन का उत्तर दें, समस्या देखें, डॉक्टर लिंक प्रदान करें, हो गया।

समूह नामों में डैश वैध आईएनआई और वैध वाईएएमएल दोनों हैं, मुझे नहीं लगता कि एक उपयोगकर्ता के रूप में मुझे अपने सभी समूहों का नाम बदलना चाहिए क्योंकि नामों का उपयोग पायथन चर नामों के रूप में नहीं किया जा सकता है?

साथ ही समूह नामों में - को पदावनत करने के इस निर्णय के पीछे तर्क पर भी सवाल उठाया। डायनेमिक इन्वेंट्री में डैश का उपयोग करने में सक्षम नहीं होना keyed_groups पहले से ही काफी कष्टप्रद था, लेकिन हमारी इन्वेंट्री फाइलों में हमारे सभी समूहों का नाम बदलना और केवल काल्पनिक सिंटैक्स-संबंधित समर्थन मुद्दों से बचने के लिए ansible-playbook -l ... कमांड है दर्दनाक होने वाला है।

FWIW हमारे पास foo_server जैसे भूमिका-समूहों के नामकरण और foo-dev या foo-test जैसे मेजबान-समूहों के नामकरण के लिए एक परंपरा है। हमारे लगभग 100% उत्तरदायी उपयोग ansible-playbook -l foo-dev जैसे कमांड हैं, इसलिए यह परिवर्तन मांसपेशी-स्मृति से लड़ने के लिए बहुत प्रयास करेगा।

सुनिश्चित नहीं है कि यहां एक और मुझे 2 जोड़ने से इस विशिष्ट निर्णय को उलटने के लिए प्रोत्साहित किया जाएगा, लेकिन मैं इस आवश्यकता के विरोधियों से सहमत हूं कि समूह के नाम वैध पायथन पहचानकर्ता हों।

कृपया समूह नामों में अक्षरों, संख्याओं और अंडरस्कोर के साथ हाइफ़न का समर्थन करें (लेकिन मेरे पास बिंदुओं के खिलाफ कुछ भी नहीं है)!

हम समूह नामों में हाइफ़न का अत्यधिक उपयोग करते हैं। दोनों इस तरह के नामों को समूहीकृत करने के लिए:

[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:

{% सेट _होस्टग्रुप = [_सर्विस, _जॉब, _क्लस्टर]|जॉइन ('_')%}
{% सेट _होस्टलिस्ट = समूह[_होस्टग्रुप]|डी([])|सॉर्ट%}
{% अगर _होस्टलिस्ट%}
{% होस्टलिस्ट में होस्ट के लिए%}
...
```

हम केवल समूह और होस्ट नामों के बीच दृश्यमान अंतर बनाने के लिए बिंदुओं का उपयोग नहीं करते हैं।

TRANSFORM_INVALID_GROUP_CHARS में INVALID शब्द कोई विश्वास नहीं देता है कि लंबे समय तक उनका उपयोग करना जारी रखना संभव है।

यदि इरादा इन वर्णों के उपयोग से बचने का है तो बेहतर है कि उन्हें _UNSAFE_ वर्ण कहें, चेतावनी दिखाएं और उपयोगकर्ताओं को यह तय करने दें कि उन्हें यह चेतावनी दिखाई देती है या नहीं। लेकिन इन पात्रों को कभी भी अस्वीकार या प्रतिस्थापित न करें!

उपयोगकर्ताओं को चाहिए कि a) इस चेतावनी को म्यूट करें (ALLOW_UNSAFE_GROUP_CHARS जैसे कीवर्ड का उपयोग करके), b) अपने समूह के नाम बदलें (जब संभव हो) या c) बस उस चेतावनी के साथ रहें। अधिकांश वैसे भी पहले दो विकल्पों में से किसी एक को चुनेंगे।

मुझे यह भी लगता है कि यह व्यर्थ है, डैश के रूप में "-" लगभग हर प्रकार के कंप्यूटर से संबंधित उपकरण में उपयोग किया जाने वाला एक मानक सीमांकक चरित्र है, और एक "धर्म" के अनुरूप होने की कोशिश करना संकुचित लगता है !!!

पुराना व्यवहार नहीं चलेगा; यह स्पष्ट रूप से पुराने व्यवहार को चुने बिना अनुपलब्ध हो जाएगा।

यदि समूह नामों में डैश में ऑप्ट-इन करना वास्तव में संभव होता तो मैं इस बहिष्करण के बारे में उतना चिंतित नहीं होता। तब इसे नए-उपयोगकर्ता के दृष्टिकोण से समझा जा सकता है।

हालाँकि, पदावनति चेतावनी का अर्थ है कि Ansible 2.10 में TRANSFORM_INVALID_GROUP_CHARS=never विकल्प दूर जा रहा है, और इसलिए हमें Ansible 2.10 जारी होने से पहले अपने सभी समूहों का नाम बदलना शुरू करना होगा?

[बहिष्करण चेतावनी]: TRANSFORM_INVALID_GROUP_CHARS सेटिंग डिफ़ॉल्ट रूप से समूह नामों में खराब वर्णों को अनुमति देने के लिए सेट है, यह बदल जाएगा, लेकिन फिर भी बहिष्करण पर उपयोगकर्ता कॉन्फ़िगर करने योग्य होगा। यह सुविधा संस्करण 2.10 में हटा दी जाएगी। deprecation_warnings=False ansible.cfg में सेट करके बहिष्करण चेतावनियां अक्षम की जा सकती हैं।

साथ ही, डायनेमिक इन्वेंट्री प्लगइन का उपयोग करना keyed_groups समूह नामों के परिवर्तन को बाध्य करता है, भले ही TRANSFORM_INVALID_GROUP_CHARS=never सेट हो: https://github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/ प्लगइन्स/इन्वेंटरी/__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 रखना है लेकिन 2.10 में डिफ़ॉल्ट को always में बदलना है - उस स्थिति में, बहिष्करण चेतावनी बहुत अच्छी तरह से नहीं है: 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

  संपादित करें: यह स्पष्ट रूप से उत्तरदायी 2.7 के लिए पिछड़ा-संगतता के लिए है, जिसने बिना शर्त रूप से जेनरेट किए गए समूह नामों को बदल दिया। इसके लिए एक स्पष्ट ऑप्ट-आउट होना बहुत अच्छा होगा।

परिवर्तनीय नामों के संबंध में, मुझे समझ में नहीं आता कि शब्दकोश कुंजी के प्रारूप को परिवर्तनीय नाम के वाक्यविन्यास के साथ बराबर क्यों किया जाना चाहिए? AFAIK किसी प्रोग्रामिंग भाषा में ऐसी सीमा नहीं है। पायथन में आप किसी भी स्ट्रिंग को शब्दकोश कुंजी के रूप में उपयोग कर सकते हैं।

"समूह" एक शब्दकोश प्रकार चर नहीं है और मेजबान और समूह नाम दोनों ही Ansible में केवल सादे शब्दकोश कुंजी हैं। वे गुण नहीं हैं और न ही चर हैं या वे हैं?

मैं समूहों ["foo-group"] की तुलना में group.foo-group वाक्यविन्यास को अस्वीकार करना चाहता हूं। यदि g = "foo-group", तो क्या आप group.g या group[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 )

यह सभी को तोड़ने वाला है। ख़राब निर्णय।

क्या इस बारे में अनुरक्षकों के साथ तर्क करने का कोई तरीका होगा?

शायद रखरखाव करने वालों में से एक यहां थोड़ा विस्तार कर सकता है, अगर यह सिर्फ एक समर्थन मुद्दा है या यदि वे पाइथन संरचनाओं का उपयोग कर रहे हैं जो वास्तव में टूट जाते हैं?

मैं बस इसे काफी कष्टप्रद जोड़ना चाहता हूं और वास्तव में समस्या का पता लगाने में असमर्थता भी कष्टप्रद थी, मुझे समस्या का पता लगाने के लिए ansible-playbook "insert yaml file here" > output.txt करना पड़ा।

यहां अधिकांश पोस्टरों से सहमत हैं। समूह के नामों से डैश को हटाना एक खराब सोचे-समझे निर्णय की तरह लगता है, या ऐसा लगता है जो कार्यान्वयन है, शब्दार्थ से प्रेरित नहीं है।

यह बदलाव मेरे लिए बिल्कुल मायने नहीं रखता। उत्तरदायी देव हजारों और हजारों उपयोगकर्ताओं को अपने समूह के नामकरण को बदलने के लिए मजबूर करना चाहते हैं क्योंकि वे समूहों तक पहुंचने के लिए एक अतिरिक्त वाक्यविन्यास (लापता नहीं) चाहते हैं? क्या यह मज़ाक है?

हम बड़े सेटअप में डैश और डॉट्स का उपयोग करते हैं।
हमारा पैटर्न product-name.environment.datacenter और यह चीजों को बहुत स्पष्ट करता है।
मैं - और . को छोड़ने की कल्पना नहीं कर सकता क्योंकि इससे इन्वेंट्री पूरी तरह से अपठनीय हो जाएगी।

हम ऐसे उत्तरदायी इन्वेंट्री प्लग इन का उपयोग कर रहे हैं जो स्थानीय सीएमडीबी को समूह नामों के लिए क्वेरी करते हैं जिनमें डैश होते हैं (और जारी रहेंगे)। यदि भविष्य में यह अमान्य होगा तो यह बहुत सारी चीज़ें तोड़ देगा।

हम बड़े सेटअप में डैश और डॉट्स का उपयोग करते हैं।
हमारा पैटर्न product-name.environment.datacenter और यह चीजों को बहुत स्पष्ट करता है।
मैं - और . को छोड़ने की कल्पना नहीं कर सकता क्योंकि इससे इन्वेंट्री पूरी तरह से अपठनीय हो जाएगी।

हम एक पदानुक्रमित नामकरण योजना के साथ एक समान दृष्टिकोण का उपयोग कर रहे हैं (जावा से प्रेरित, जैसे org.company.product-name.component)।
अंडरस्कोर पर वापस लौटना एक पूर्ण डरावनी स्थिति होगी।

हे हमने उस मुद्दे का भी सामना किया। हम अपने समूहों के नामों में डैश का गहनता से उपयोग कर रहे हैं।
अगर कोई समझा सकता है कि किसी निर्देश में डैश के उपयोग के कारण क्या समस्या है तो मुझे यह जानकर खुशी होगी

मैं मुख्य रूप से वही दोहरा रहा हूं जो दूसरों ने कहा है, लेकिन मैं कुछ इनपुट जोड़ना चाहता था। मुझे लगता है कि यदि यह परिवर्तन लागू किया जाता है, तो ध्वज को डैश की अनुमति देने के लिए रखा जाना चाहिए और बनाए रखा जाना चाहिए। हालांकि मैं समझता हूं कि पायथन अंडरस्कोर की अपेक्षा करता है, डैश आमतौर पर होस्ट नामों और होस्ट समूह नामों के लिए उपयोग किया जाता है। हमारे परिवेश में हम अपनी LDAP/Kerberos निर्देशिका में होस्ट और होस्ट समूहों से गतिशील रूप से इन्वेंट्री जेनरेट करते हैं। मैं इसका उल्लेख इसलिए करता हूं क्योंकि यद्यपि हमारे लिए मेजबान और समूह के नाम बदलना संभव होगा, यह बेहतर नहीं है।

इस कार्यक्षमता से बाहर निकलने के लिए हमें क्या करना चाहिए? हमारी स्थानीय Ansible परिनियोजन स्क्रिप्ट हाइफ़न-युक्त समूह नामों से अटी पड़ी हैं। हम निश्चित रूप से डॉट नोटेशन के साथ उनका उपयोग नहीं करते हैं। लेकिन उन सभी को बदलना वास्तव में एक महत्वपूर्ण कार्य होगा। मैं ऑप्ट आउट करना पसंद करूंगा और साथ ही साथ अपनी टीम को भविष्य में हाइफ़न का उपयोग करने से बचने के लिए प्रोत्साहित करूंगा और जहां संभव हो वहां हाइफ़न को अंडरस्कोर में परिवर्तित करना होगा, क्योंकि अंतिम भाग हमेशा उतना सीधा नहीं होता जितना यह लग सकता है।

तो, क्या कोई केवल force_valid_group_names = false को ansible.cfg में सेट करता है? यह d241794#diff-fd24ad93fbc32f454761746c1ac908f2 पर आधारित सही लगता है

Ansible 2.8.2 पर परीक्षण करें, यह INI सेटिंग अपेक्षित रूप से काम नहीं करती है, मुझे विश्वास है, यह केवल DEPRECATION WARNING को हटा देगा, जबकि, मैं जो चाहता हूं, वह Ansible के लिए बिना किसी शिकायत के डैश के साथ मेरे समूहों का उपयोग करना है।

यहां बिना परिणाम दिए गए हैं:

[बहिष्करण चेतावनी]: TRANSFORM_INVALID_GROUP_CHARS सेटिंग डिफ़ॉल्ट रूप से समूह नामों में खराब वर्णों को अनुमति देने के लिए सेट है, यह बदल जाएगा, लेकिन फिर भी बहिष्करण पर उपयोगकर्ता कॉन्फ़िगर करने योग्य होगा। यह सुविधा संस्करण 2.10 में हटा दी जाएगी। प्रतिवाद
ansible.cfg में deprecation_warnings=False सेट करके चेतावनियों को अक्षम किया जा सकता है।
[चेतावनी]: समूह नामों में अमान्य वर्ण पाए गए लेकिन बदले नहीं गए, विवरण देखने के लिए -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 अनुवाद करने के लिए क्यों मजबूर करना चाहिए।

आज का दिन वाकई बहुत दुखद है.. जब एक जेआर सहकर्मी ने मेरे लिए यह पदावनत किया तो मुझे लगा कि इस तरह का स्वार्थी विकल्प बनाने के लिए अंसिबल टीम वास्तविकता के संपर्क से इतनी दूर नहीं होगी। मैं पूरी तरह से Ansible से प्यार करता हूं जो इसे पूरा कर सकता है (एक उपयोगकर्ता के नजरिए से जिसमें ZERO का संबंध पायथन में लिखा जा रहा है) अंतिम उपयोगकर्ताओं पर PEP मानकों को आगे बढ़ाने के लिए यहां की दिशा ने मुझे कोर Ansible डेवलपमेंट टीम की क्षमता बनाने में पूरी तरह से ढीला कर दिया है। तर्कसंगत निर्णय। मुझे आशा है कि आईबीएम इसे सीधा करेगा ..
या
हो सकता है कि एक नया-चमकदार GO समकक्ष होगा जिसे हम आगे बढ़ा सकते हैं।

चूंकि यह व्यवहार स्पष्ट रूप से बहुत विवादास्पद है, मैं अपने आप से पूछ रहा हूं कि क्या यह एक पूर्ण सौदा है और इसे किसी भी मामले में लागू किया जा रहा है?

मैं इस निर्णय के पीछे लोगों की प्रतिक्रिया की बहुत सराहना करता हूं और "यह एक अजगर मानक चीज है" से परे कुछ विस्तार की आशा करता हूं।

चूंकि यह व्यवहार स्पष्ट रूप से बहुत विवादास्पद है, मैं अपने आप से पूछ रहा हूं कि क्या यह एक पूर्ण सौदा है और इसे किसी भी मामले में लागू किया जा रहा है?

मैं इस निर्णय के पीछे लोगों की प्रतिक्रिया की बहुत सराहना करता हूं और "यह एक अजगर मानक चीज है" से परे कुछ विस्तार की आशा करता हूं।

मैं आपसे सहमत हूं। अभी हाल ही में "गो" परियोजना एक अलोकप्रिय प्रस्ताव से समर्थित है (देखें https://github.com/golang/go/issues/32437#issuecomment-512035919), इसलिए इस तरह की चीजें (और कभी-कभी होनी चाहिए) पर दोबारा गौर किया जा सकता है और अंततः भी पीछे हट गए।

यह एक दिलचस्प विषय और चर्चा भी है, शायद इस सुविधा परिवर्तन के लिए ही नहीं। यह पता लगाना कठिन है कि उत्पाद के रूप में Ansible का शासन कैसे काम करता है। शायद कुछ _someone_ को अपने साथ https://www.ansible.com/ansiblefest पर लाना चाहिए?

जैसा कि हम में से बहुत से लोग अपना सिर खुजला रहे हैं, यह समझ नहीं पा रहे हैं कि कैसे एक स्ट्रिंग/चर सामग्री/समूह का नाम किसी भी तरह से पाइथन कोडिंग शैलियों के साथ किसी भी समस्या का सामना कर सकता है, रखरखावकर्ताओं से यहां जवाब प्राप्त करना अच्छा होगा, यह तर्क देते हुए कि यह क्यों होगा मुद्रा एक मुद्दा।

मैं समझ सकता हूं कि क्या वे चर नामों और संरचनाओं के लिए एक कोडिंग शैली रखना चाहते हैं, लेकिन एक सरणी या चर की सामग्री?

यहां डिक्ट्स के डॉट नोटेशन के बारे में एक त्वरित चर्चा है। यह संभव है, लेकिन बदसूरत। 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 का उपयोग करें। इसका मतलब है कि सभी मौजूदा ansible.cfg फाइलों को बदलने की जरूरत है।

या वैश्विक डिफ़ॉल्ट सेट करने का कोई तरीका है (उपयोगकर्ता पर्यावरण में कोई अन्य चर जोड़े बिना)?

@ कौगर ने सहमति व्यक्त की कि

आपकी समस्या हालांकि इस सेटिंग के लिए अद्वितीय नहीं है .. हमने समान दर्द का अनुभव किया और अब हम प्रति-प्रोजेक्ट ansible.cfg फ़ाइलों के उपयोग को हतोत्साहित करते हैं क्योंकि अधिकांश सेटिंग्स पर्यावरण चर के साथ सेट की जा सकती हैं जो cfg फ़ाइल सेटिंग्स को ओवरराइड करती हैं .. इसलिए यदि कोई प्रोजेक्ट कुछ अस्पष्ट कारणों के लिए एक विशिष्ट सेटिंग की आवश्यकता होती है जो हम पूछते हैं कि वे ENV पद्धति का उपयोग करते हैं जो बाकी सेटिंग्स को छोड़ देता है जिन्हें उन्हें कॉर्पोरेट मानकों पर सेट करने की आवश्यकता नहीं होती है। हम इस मानक कॉन्फ़िगरेशन के साथ एक बेस डॉकटर कंटेनर का निर्माण करते हैं और अलग-अलग प्रोजेक्ट्स बेस एन्सिबल कंटेनर की अपनी छवि को आधार बनाते हुए अपने स्वयं के डॉकरफाइल में ईएनवी प्रविष्टियां जोड़ते हैं। सभी ansible को कंटेनर के भीतर निष्पादित किया जाता है, इसलिए हम निश्चित हैं कि सभी pip मॉड्यूल, ansible संस्करण और रनटाइम टूल एंड टू एंड समान हैं।

संपादित करें: यह हमें कंपनी में हर किसी के साथ हिट होने से पहले इस तरह के उत्तरदायी और नियंत्रण मुद्दों के नए संस्करणों में मंच करने की क्षमता भी देता है :)

मैंने कुछ खुदाई की।

इस कार्यक्षमता को मूल रूप से पीआर 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, आदि में, मेजबानों को समूहों में मैप करने के लिए।

यदि हम होस्ट नामों के लिए समान मानक/नामकरण परंपरा का उपयोग करते हैं, तो हम निश्चित रूप से गति खो देंगे और उपयोगकर्ताओं को खो देंगे।

समूह का नाम एक नाम है, चर नहीं। समूह नामों में डैश का उपयोग करना (जैसे होस्ट नामों में) समझ में आता है। अनुवाद (स्वच्छता) को एक इन्वेंट्री स्तर (हमारे द्वारा, उपयोगकर्ताओं द्वारा) पर करने की आवश्यकता नहीं होनी चाहिए, और सभी दुनिया के सर्वश्रेष्ठ में वास्तव में कभी नहीं।

मुझे वास्तव में इसे लागू करने का लाभ नहीं दिख रहा है। ऐसा लगता है कि चर्चा भी "।" और ":", जिसे कुछ लोग समूह नामों में उपयोग करना पसंद करते हैं। व्यक्तिगत रूप से मैं उनका उपयोग नहीं करता, लेकिन मुझे ऐसा करने में कोई नुकसान भी नहीं दिखता।

जब तक क्लाउड प्रदाता अपनी मेटा जानकारी में डैश का उपयोग कर रहे हैं, तब तक हमें उन्हें समूहीकरण के लिए उपयोग करने में सक्षम होना चाहिए। दरअसल, वह ड्राइवर भी नहीं होना चाहिए। अगर मुझे लगता है कि किसी समूह का नामकरण एबीसीडीई करना है, तो यह वास्तव में कोई मुद्दा नहीं होना चाहिए। यह एक बहुत ही उपयोगी सीमांकक है।

हालाँकि, यह धागा देवों या अनुरक्षकों का ध्यान आकर्षित नहीं करता है। मुझे लगता है कि हम बहरे कानों से बात कर रहे हैं।

देव/रखरखाव: कृपया, कृपया समूह नामों में डैश की अनुमति दें!

कुछ गलतफहमियों को स्पष्ट करने के लिए, उनमें से कुछ मेरी गलतियों के कारण थे और शुरुआती संदेशों को अस्पष्ट बना रहे थे, नवीनतम संस्करणों में कुछ मुद्दों को ठीक किया गया है जो लोग यहां लाते रहते हैं, अन्य सुधार अभी भी कम हैं:

बस एक बार यह स्पष्ट रूप से कहने के लिए, आप हमेशा समूह नामों में डैश का उपयोग करने में सक्षम होंगे, डॉट्स और अन्य वर्ण जिन्हें अब 'अमान्य' माना जाता है, बस डिफ़ॉल्ट रूप से नहीं। यह 'डिफ़ॉल्ट' है जिसे बहिष्कृत किया जा रहा है, डिफ़ॉल्ट 2.11 में 'सुरक्षित' होगा, लेकिन आपके पास हमेशा पुराने व्यवहार को 'ऑप्ट इन' करने का विकल्प होगा।

और यह समझाने के लिए कि हम यहां कैसे और क्यों पहुंचे:

सबसे पहले, समूह के नाम हमेशा साफ-सुथरे थे, उनके पास अलग-अलग असंगत नियम थे, आपके द्वारा उपयोग किए जा रहे इन्वेंट्री प्रकार के आधार पर, स्क्रिप्ट सभी जगह थीं, YAML और INI प्रारूपों में से प्रत्येक ने अपना काम किया। बड़ा बदलाव 'स्वच्छता का केंद्रीकरण और सामान्यीकरण' था, यह 2.4 में वापस तय किया गया था लेकिन 2.8 तक पूरी तरह से लागू नहीं किया गया था। इरादा एक मानदंड या आधार रेखा प्रदान करना था जो सभी अंसिल्बे में सुरक्षित रूप से उपयोग कर सकते थे, जिसमें कहा गया था कि हम मानते हैं कि चर के लिए 'असुरक्षित' या 'अमान्य' वर्णों का उपयोग करने वाले कई लोग हैं, इसलिए हमने न केवल विश्व स्तर पर बल्कि कुछ लोगों द्वारा भी इसे कॉन्फ़िगर करने योग्य बनाया है। इन्वेंट्री प्लगइन्स।

प्रारंभिक कार्यान्वयन में कुछ मुद्दे थे और बहुत सारी चर्चाएं थीं (नहीं, हम इसे छुपाकर तय नहीं करते हैं, हमारे पास आईआरसी में सार्वजनिक बैठकें हैं जिनमें आप सभी का स्वागत है, https://github.com/ansible/community/blob/master /meetings/README.md) और बहुत सारी प्रतिक्रिया शामिल की गई थी (ये भी लॉग की गई हैं ताकि आप चर्चा और तर्क देखने के लिए वापस जा सकें, लेकिन 'लॉग डंपस्टर डाइविंग' से बचने के लिए, मैं नीचे दिए गए अधिकांश मुद्दों को समझाऊंगा) . 2.8 में बाहर जाने के बाद हमें फीडबैक का एक और दौर मिला और हम कुछ बग्स को ठीक कर रहे हैं, जैसे हमेशा एक डिप्रेशन प्राप्त करना, न कि केवल डिफ़ॉल्ट का उपयोग करते समय और विशेष रूप से दस्तावेज़ीकरण और चेतावनियों के शब्दों के साथ।

• 'पायथन नाम क्यों?'
  अधिकतर क्योंकि Ansible Python और JInja (जो कि Python का भी उपयोग करता है) का उपयोग करता है और समूहों के कुछ उपयोग (ज्यादातर हमारे शुरुआती उदाहरणों में, लेकिन बहुत सारे 3rd पार्टी वाले भी) प्लेबुक में त्रुटियां पैदा कर सकते हैं, यानी stuff: '{{ groups.gropup-name-with-dash ... }}' या इससे भी बदतर group.name.with.dots । यह कई उपयोगकर्ताओं के लिए भ्रम पैदा करता है जो 'डॉट नोटेशन फॉर वेरिएबल एक्सेस' की जिंजा सुविधा का उपयोग करना चाहते हैं और यही कारण है कि डिफ़ॉल्ट सभी उपयोगकर्ताओं के लिए सुरक्षित होना चाहिए। इस पोस्ट पर अधिकांश लोग इससे असहमत हो सकते हैं, लेकिन यह बहुत से लोगों के लिए एक वास्तविक मुद्दा है और नए या पुराने Ansible उपयोगकर्ताओं के लिए 'जाल' नहीं होना चाहिए। जो लोग 'ऑप्ट आउट' करते हैं, वे Ansible के अन्य भागों में उपयोग को तोड़ने से बचने के लिए जिम्मेदार होते हैं।

• 'क्या होगा अगर मुझे पसंद आया कि प्रत्येक सूची में अलग-अलग स्वच्छता थी?'
  ठीक है, आप अभी भी 'केंद्रीय' स्वच्छता को बंद कर सकते हैं और अपने विशिष्ट इन्वेंट्री स्रोत के लिए एक को सक्षम कर सकते हैं, पुरानी स्क्रिप्ट को प्रतिस्थापित करने वाले सबसे लोकप्रिय नए इन्वेंट्री प्लगइन्स में स्क्रिप्ट व्यवहार का अनुकरण करने के लिए विकल्प जोड़े गए हैं, सबसे खराब स्थिति, आप अभी भी उपयोग कर सकते हैं इन्वेंट्री स्क्रिप्ट।

• 'होस्टनाम क्यों नहीं/होस्टनाम अगले हैं?'
  समूहों की तरह, होस्टनामों का स्वच्छताकरण हमेशा अस्तित्व में रहा है, लेकिन बदला नहीं है, होस्टनामों की एक अलग आवश्यकताएं हैं, जैसे DNS समाधान योग्य होना
  नेटवर्क कनेक्शन के लिए या क्रोट कनेक्शन के लिए एक वैध पथ के लिए। इसके अलावा, सौभाग्य से, डॉट नोटेशन में होस्टनाम का उपयोग करने के बहुत कम या कोई उदाहरण नहीं हैं, यह एक सामान्य प्रथा नहीं रही है और अगर लोग अचानक उनका उपयोग करना शुरू कर देते हैं तो यह एक समस्या बन जाएगी, लेकिन समूह नामों के विपरीत यह कुछ ऐसा है जिसे हमने अब तक टाला है। अगर यह आगे चलकर समस्या बन जाती है ... मुझे कोई अच्छा समाधान भी नहीं दिखता।

ध्यान दें कि यह विशिष्ट टिकट (पर्याप्त विवरण/सूचना नहीं है) कुछ ऐसा है जिसे मैं पहले से ही संबोधित कर रहा हूं, उम्मीद है कि जल्द ही ठीक हो जाएगा। बाकी चर्चा के लिए, देव जीथब को एक मंच के रूप में उपयोग नहीं करते हैं, कुछ टिकट उसमें विकसित होते हैं, पिछले टिकट जो बंद है और एक लंबा धागा भी है, हाल ही में अनदेखा किया गया था, ज्यादातर क्योंकि देव बंद मुद्दों को फ़िल्टर करते हैं और आईआरसी में मेलिंग सूची या नए मुद्दों पर चर्चा की अपेक्षा करें।

मुझे उम्मीद है कि यह सभी प्रमुख मुद्दों को संबोधित करता है, हमेशा की तरह हम चर्चा के लिए खुले हैं, एमएल या आईआरसी द्वारा ड्रॉप करने के लिए स्वतंत्र महसूस करें, हम सिर्फ जीथब का उपयोग करने से बचते हैं क्योंकि यह ऐसी चीजों के लिए एक अच्छी जगह नहीं है।

स्पष्टीकरण के लिए बहुत-बहुत धन्यवाद।

आपको समझाने के लिए समय निकालने की सराहना करते हैं, भले ही डॉट नोटेशन का समर्थन करना बंद करना और कुछ रिलीज़ पर उस समर्थन को बहिष्कृत करना कहीं अधिक सरल होता। कम लोग इसका उपयोग करते हैं बनाम उन लोगों की संख्या जिनके समूह नामों में अमान्य वर्ण हैं। से ला विए

@skyscooby समस्या यह है कि यह ऐसा करने के लिए उत्तरदायी नहीं है, यह जिन्जा है।

बस एक बार यह स्पष्ट रूप से कहने के लिए, आप हमेशा समूह नामों में डैश का उपयोग करने में सक्षम होंगे, डॉट्स और अन्य वर्ण जिन्हें अब 'अमान्य' माना जाता है, बस डिफ़ॉल्ट रूप से नहीं।

ठीक है, यह जानना अच्छा है, स्पष्टीकरण के लिए धन्यवाद। हालांकि, उपयोगकर्ता अनुभव में वास्तव में सुधार करने की आवश्यकता है। आपके पास "ज्ञान का अभिशाप" है। बस इसे देखने वाले उपयोगकर्ता के स्थान पर स्वयं की कल्पना करने का प्रयास करें:

[बहिष्करण चेतावनी]: TRANSFORM_INVALID_GROUP_CHARS सेटिंग डिफ़ॉल्ट रूप से समूह नामों में खराब वर्णों को अनुमति देने के लिए सेट है, यह बदल जाएगा, लेकिन फिर भी
बहिष्करण पर कॉन्फ़िगर करने योग्य उपयोगकर्ता। यह सुविधा संस्करण 2.10 में हटा दी जाएगी। deprecation_warnings=False ansible.cfg में सेट करके बहिष्करण चेतावनियां अक्षम की जा सकती हैं।
[चेतावनी]: समूह नामों में अमान्य वर्ण पाए गए लेकिन बदले नहीं गए, विवरण देखने के लिए -vvvv का उपयोग करें

यह एक लंबा, लंबा रास्ता है

[बहिष्करण चेतावनी] समूह नाम 'my-servers' में '-' शामिल है, जो डिफ़ॉल्ट रूप से Ansible 2.11 से अमान्य हो जाएगा। इसे दबाने के लिए force_valid_group_names को ansible.cfg या ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS पर्यावरण चर को "अनदेखा" करने के लिए सेट करें। अधिक जानकारी के लिए https://docs.ansible.com/something देखें।

... जो मैं, एक उपयोगकर्ता के रूप में, वास्तव में देखना चाहता था। यह मुझे एक घंटे से अधिक बचा लेता। अब इसे उन लोगों की संख्या से गुणा करें जिनके पास इस समस्या का सामना करना पड़ा है या होगा।

समूह-नामों में डैश और डॉट्स का अमान्य होना एक समझदार डिफ़ॉल्ट नहीं है। लोगों के पास हमेशा उनके समूह के नाम होंगे। समझदार व्यवहार को सक्षम करने के लिए उन्हें कॉन्फ़िगरेशन फ़ाइल में एक और चर सेट करने की आवश्यकता के लिए आईएमएचओ अनिश्चित है।

ऊपर आपकी टिप्पणी के लिए धन्यवाद @bcoca । इसकी बहुत सराहना की जाती है।

हालांकि मैं इस फैसले से खुश नहीं हूं, लेकिन मैं समझता हूं कि एक चर्चा हुई और एक निर्णय लिया गया। यदि निर्णय अभी भी बहस के लिए खुला है तो इसे मेलिंग सूची या आईआरसी पर जारी रखा जाना चाहिए लेकिन इस मुद्दे पर कब्जा नहीं हो सकता है।

इस मुद्दे के विषय के लिए मैं इस परिवर्तन के बारे में जागरूक होने के लिए आधिकारिक दस्तावेज और पोर्टिंग गाइड में निम्नलिखित जानकारी प्राप्त करना चाहता हूं।

• समूह नाम क्या हैं जो डिफ़ॉल्ट रूप से मान्य हैं?
• डैश, हाइफ़न, डॉट्स और कोलन सहित समूह नामों का उपयोग करते रहने के लिए क्या करें?

क्योंकि हम अपने सभी समूह और होस्ट नामों में डैश का उपयोग करते हैं और हम इसे नहीं बदलेंगे। इसलिए जब भी मैं एक नया इंस्टॉलेशन/वातावरण सेटअप करता हूं, तो मुझे हर बार अपना ansible.cfg ऑप्ट-इन करना होगा और अपना

चर्चा जारी रखने के लिए कि यह परिवर्तन बुद्धिमान है या नहीं, मैंने Ansible Development Group में एक सूत्र खोला।

सादर,
ट्रोंडे

मैं इस मुद्दे पर सभी योगदानकर्ताओं को धन्यवाद देना चाहता हूं। मैंने यहां जो पढ़ा उसके आधार पर मैंने एक ब्लॉग पोस्ट https://docs.sbarnea.com/ansible/naming-hosts-and-groups लिखने का फैसला किया - उम्मीद है कि यह संक्षेप में बताएगा कि उपयोगकर्ताओं को क्या करने की आवश्यकता है।

@ लूप-एवगेनी मैं मानता हूं कि कोर टीम के रूप में हमारे पास "ज्ञान का अभिशाप" है और यह हमें ऐसे दस्तावेज़ और त्रुटियां बनाने से रोकता है जो सभी के लिए उपयोगी हैं। हम पूरी तरह से समुदाय पर भरोसा करते हैं ताकि हमें उत्तरदायी आकार देने में मदद मिल सके और जितना संभव हो उतने उपयोगकर्ताओं के लिए इसे सरल रखा जा सके, इसलिए जब लोगों के पास हमारे दस्तावेज़ों और हमारे त्रुटि/चेतावनी संदेशों को बेहतर बनाने के लिए अनुशंसाएं होती हैं, तो मैं हमेशा उन्हें एक भेजकर हमारी सहायता करने के लिए प्रोत्साहित करता हूं पुल अनुरोध। आपके द्वारा इंगित किया गया संदेश निम्न फ़ाइल में है और यदि आप हमें सुझाए गए परिवर्तन के साथ एक पीआर भेज सकते हैं तो हम इसकी बहुत सराहना करेंगे ...

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

@jctanner आमतौर पर मेरे द्वारा उपयोग किए जाने वाले एक निःशुल्क और उपयोगी कार्यक्रम को बेहतर बनाने के लिए एक पीआर सबमिट करने में मुझे खुशी होगी। हालांकि, प्रयोज्य डेवलपर्स का प्रयोज्यता के प्रति सामान्य रवैया, "इच्छित के रूप में काम करने" के रूप में बंद करने की उनकी उत्सुकता, जिन्हें मैं स्वयं-स्पष्ट बग (भले ही डिज़ाइन बग) मानता हूं और तथ्य यह है कि वर्तमान में 2025 (यह दो हजार है) !) खुले पीआर मुझे बहुत कम विश्वास दिलाते हैं कि मेरा काम बेकार नहीं जाएगा। यदि आप वास्तव में "समुदाय पर भरोसा" करना चाहते हैं, जैसा कि आप कहते हैं, तो एक महत्वपूर्ण संस्कृति परिवर्तन की आवश्यकता है IMHO।

हम्म.. उस मौके ने मुझे भी मारा।

दुर्भाग्य से हम नेटवर्क नामों का उपयोग समूह नामों के रूप में करते हैं और यह आसानी से परिवर्तित नहीं किया जा सकता है। मुझे समूह नामों के लिए डॉट सिंटैक्स शुगर का विकल्प चुनना अच्छा लगेगा क्योंकि ऐसा कुछ भी नहीं है जिसका मैंने कभी उपयोग किया है (हालांकि मैं इसे अन्य चर के साथ उपयोग करता हूं)।

भविष्य में 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 = उपेक्षा के साथ अनदेखा करता हूं, तो यह आवश्यक होगा, और जब मैं Ansible>= 2.10 में अपग्रेड करूं?

सादर,
सीजर जॉर्ज

अगर मैं इसे सही ढंग से समझता हूं। केवल एक चीज जिसे पदावनत किया गया है वह है समूह नामों का स्वत: परिवर्तन। इसका मतलब है कि 2.10 और उसके बाद force_valid_group_names = ignore सेट करना पूरी तरह से ठीक होना चाहिए।

डैश और समूह नामों में जो कुछ भी आप चाहते हैं उसका उपयोग जारी रखना भी पूरी तरह से ठीक होना चाहिए। भविष्य में 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 ने स्पष्ट रूप से समूह के नामों के लिए हमेशा कुछ स्वच्छता की। इसका मतलब है कि उपरोक्त उदाहरणों में foo_bar_xyz का उपयोग करना संभव था (और 2.10 तक अभी भी है) भले ही समूह को वास्तव में foo-bar.xyz कहा जाता है। व्यक्तिगत रूप से मुझे नहीं लगता कि इससे चीजें आसान हो जाती हैं और ऐसा लगता है कि अब कोर टीम भी इससे सहमत है।
इसलिए इस मुद्दे से निपटने का उनका अगला प्रयास "अमान्य" समूह के नामों को पहले स्थान पर रखना असंभव बनाना है। हालाँकि जहाँ तक मैं समझता हूँ कि force_valid_group_names = ignore सेट करके इस सीमा से बाहर निकलना हमेशा संभव होगा।

लंबी कहानी संक्षेप में यह वास्तव में दो अलग-अलग परिवर्तन हैं जो एक दूसरे के साथ जुड़े हुए हैं [1]। जहां से भ्रमित करने वाला नाम और चेतावनी का शब्दांकन।

फिर से मैं इस मुद्दे को कैसे समझता हूं। मुझे सही जवाब दो अगर मैं गलत हूँ!

[1] अधिक जानकारी के लिए देखें RFC1925 पैराग्राफ 2, बिंदु (5)

मैं बस अपना 2¢ छोड़ना चाहता था क्योंकि मैं दृढ़ता से डैश> अंडरस्कोर के पक्ष में हूं। बस मामले पर एक त्वरित

यहां तक ​​​​कि अगर ऐसा नहीं था, तो तथ्य यह है कि मैं जंगली में सर्वर लेबल और समूहों जैसी चीजों के लिए उपयोग किए जाने वाले डैश को अंडरस्कोर की तुलना में बहुत अधिक बार देखता हूं, इसका मतलब है कि यह एक और चीज होगी जिसे मुझे अपने सभी में जोड़ना सुनिश्चित करना होगा और मेरे क्लाइंट की ansible.cfg फाइलें (मेरे पास प्रति प्लेबुक एक है)।

मुझे एक सख्त डिफ़ॉल्ट को मजबूर करने की कोशिश करने में कोई समस्या नहीं है, जहां यह अनुभव में सुधार करता है, लेकिन पहले आप मेरी भूमिका के नामों में डैश के लिए आए (और कभी-कभी पुरानी भूमिकाओं के लिए एकवचन अपवादों की अनुमति दी गई थी), फिर आप डैश के लिए आए मेरे संग्रह (उन्हें किसी भी तरह, आकार या रूप में अनुमति नहीं है), और अब आप मेरी सूची में डैश के लिए आए हैं!

यह डैश के खिलाफ एक युद्ध है... और मैं कहीं एक रेखा खींचना चाहता हूं—इस मामले में, यह एक ऐसा स्थान है जहां लोगों को डैश का उपयोग करने से रोकना वास्तव में असंभव है, क्योंकि कई गतिशील इन्वेंट्री प्रदाता समूह आधारित समूह बनाते हैं सर्वर नाम और लेबल पर, और कई (यदि अधिकतर नहीं) संगठन डैश का उपयोग करके चीजों को लेबल करते प्रतीत होते हैं (उदाहरण us-east-1a , न कि us_east_1a )।

यह डिफ़ॉल्ट होने में मज़ेदार नहीं है कि सॉफ़्टवेयर को काम करने के लिए लगभग हमेशा ओवरराइड किया जाना चाहिए, लेकिन ऐसा लगता है कि Ansible 2.11 के रूप में ऐसा ही होने जा रहा है।

यदि यह सब इसलिए है क्योंकि जिनजा 2 और पायथन से अपरिचित कुछ उपयोगकर्ताओं को यह नहीं पता है कि something.with-some-dashes अमान्य है, तो मैं तर्क दूंगा कि उन्हें सिखाना बेहतर होगा "यदि डैश हैं, तो आपको डिक्ट एक्सेस के लिए ब्रैकेट नोटेशन का उपयोग करना चाहिए, उदाहरण के लिए something['with-some-dashes'] । यदि आवश्यक हो तो आप दोनों को आपस में मिला भी सकते हैं। यह सुपर शुद्ध और समग्र नहीं है, लेकिन हम यहां सभी रस्ट डेवलपर नहीं हैं ...

बहुत अच्छी तरह से रखा, जेफ। मैं यहां आपके साथ दृढ़ता से सहमत हूं - यह परिवर्तन इतना विघटनकारी होगा, और केवल एकबारगी माइग्रेशन की आवश्यकता के बजाय, बड़ी संख्या में उपयोगकर्ताओं के वर्कफ़्लो को बदल देगा। Ansible अब लीक से हटकर काम नहीं करेगा।

होस्टनाम में अंडरस्कोर शामिल नहीं हो सकता है, इसलिए एक समझदार दुनिया में, इन्वेंट्री_होस्टनाम को मजबूर नहीं किया जाएगा। इसका मतलब यह है कि हमारी सूची अब काफी असंगत दिखाई देगी, जिसमें होस्टनाम अंडरस्कोर नहीं हो सकते हैं, और ऐसे समूह जिनमें हाइफ़न नहीं हो सकते हैं।

कृपया, बस डिफ़ॉल्ट स्विच न करें।

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

नमस्ते,
मैं यहां जेफ से पूरी तरह सहमत हूं।

लेकिन जैसा कि @bcoca ने ऊपर कहा है, अधिकांश डेवलपर्स इन चर्चाओं को यहां नियमित आधार पर नहीं देखते हैं और यह मुद्दा बदलाव पर चर्चा करने के लिए सही जगह नहीं हो सकता है क्योंकि यह सही दस्तावेज के बारे में है।

चर्चा के लिए कृपया थ्रेड में शामिल हों क्या TRANSFORM_INVALID_GROUP_CHARS की डिफ़ॉल्ट सेटिंग को बदलना एक अच्छा विचार है? Google समूह में।

महान अंक जेफ।

यह डिफ़ॉल्ट होने में मज़ेदार नहीं है कि सॉफ़्टवेयर को काम करने के लिए लगभग हमेशा ओवरराइड किया जाना चाहिए, लेकिन ऐसा लगता है कि Ansible 2.11 के रूप में ऐसा ही होने जा रहा है।

इन सभी चर्चाओं से मेरे लिए यह बड़ी उपलब्धि है। मैं उस समस्या को समझता हूं जिसे हल करने की आवश्यकता है, लेकिन समाधान आवश्यक के विपरीत प्रतीत होता है। यह समर्थन के लिए चीजों को आसान बनाता है लेकिन उपयोगकर्ताओं के लिए कठिन बनाता है - यह एक पिछड़ा समाधान है।

यदि यह सब इसलिए है क्योंकि कुछ उपयोगकर्ता जिन्जा 2 और पायथन से अपरिचित हैं, तो कुछ का एहसास नहीं है। कुछ-डैश अमान्य है, मैं तर्क दूंगा कि उन्हें सिखाना बेहतर होगा "यदि डैश हैं, तो आपको डिक्ट एक्सेस के लिए ब्रैकेट नोटेशन का उपयोग करना चाहिए, उदाहरण के लिए कुछ ['साथ-कुछ-डैश']। जरूरत पड़ने पर आप दोनों को आपस में मिला भी सकते हैं।

यह यहां सबसे अच्छा समाधान है, न कि उन चीजों को तोड़ना जो सालों से इस्तेमाल की जा रही हैं।

@geerlingguy की शानदार टिप्पणी - हाजिर!

मैं इसे Ansible के उपयोगकर्ता के रूप में जोड़ना चाहता हूं, मुझे यह जानने की आवश्यकता क्यों है कि वैध पायथन सिंटैक्स क्या है? लंबे समय से Ansible का उपयोग करने के बाद, मैं समझता हूं कि Ansible (और इसके मॉड्यूल) Python में लिखे गए हैं, लेकिन मुझे इसकी परवाह क्यों करनी चाहिए? उस तथ्य को अंतिम उपयोगकर्ता के सामने उजागर करना केवल खराब डिज़ाइन है।

किसी वेब एप्लिकेशन में उपयोगकर्ता नाम जैसी चीज़ों के लिए केवल मान्य JavaScript/Ruby/.NET/जो कुछ भी नोटेशन की अनुमति देने के समान है। अंतिम उपयोगकर्ता क्यों परवाह करेगा कि आवेदन किस भाषा में लिखा गया है?

इसके अलावा, ब्रेकिंग परिवर्तन शुरू करना एक कठिन विषय है, यदि संभव हो तो मैं इससे बचने की कोशिश करता हूं। अगर मुझे कोई बदलाव करना है, तो मैं आम तौर पर पुराने, मौजूदा व्यवहार को डिफ़ॉल्ट के रूप में छोड़ देता हूं, और लोगों को नए व्यवहार के लिए ऑप्ट-इन करने देता हूं। यह यहाँ क्यों नहीं किया गया? मुझे या तो अपना कॉन्फिगरेशन क्यों बदलना है, या अपनी पूरी इन्वेंट्री को खराब करना है? दूसरी तरफ क्यों नहीं?

यदि किसी सिस्टम को आंतरिक रूप से कड़ाई से अनुपालन टोकन की आवश्यकता होती है, तो सिस्टम को आंतरिक रूप से टोकन उत्पन्न करना चाहिए और एक लुकअप टेबल बनाना चाहिए जो आंतरिक टोकन को उपयोगकर्ता डेटा के साथ जोड़ता है। इस तरह Ansible अपने टोकन नियमों को आवश्यकतानुसार बदल सकता है और उपयोगकर्ताओं पर प्रभाव को सीमित कर सकता है। उपयोगकर्ताओं को अपनी इन्वेंट्री, भूमिकाओं आदि को नाम देने में सक्षम होना चाहिए जैसा कि वे या उनके ग्राहक फिट देखते हैं।

मुझे ऐसा लगता है कि यह परिवर्तन इसके इच्छित प्रभाव के विपरीत हो सकता है (समर्थन प्रश्नों को कम करने के लिए):

अब कोई सीमांकक समर्थित नहीं है (डिफ़ॉल्ट रूप से) दोनों होस्टनामों द्वारा (जो कि DNS समाधान योग्य होना चाहिए, अर्थात, अंडरस्कोर नहीं होना चाहिए) और समूह नाम (जिसमें डैश नहीं होना चाहिए)।

निश्चित रूप से किसी भी मेजबान का नाम लेने के लिए स्वतंत्र होना चाहिए

एल मि।, 14 पहले। 2019 16:16, क्रिश्चियन प्वाइंटर नोटिफिकेशन @github.com
विवरण:

अगर मैं इसे समझूं
https://github.com/ansible/ansible/issues/56930#issuecomment-516863432
सही ढंग से। केवल एक चीज जिसे पदावनत किया गया है वह है स्वचालित
समूह के नामों का परिवर्तन। इसका मतलब है कि force_valid_group_names . सेट करना पूरी तरह से ठीक होना चाहिए
= 2.10 और उसके बाद की उपेक्षा करें।

डैश और आप जो कुछ भी उपयोग करना जारी रखना भी पूरी तरह से ठीक होना चाहिए
समूह के नाम में नहीं होगा। भविष्य में Ansible क्या नहीं करेगा, वह है सैनेटाइज़ करना
उन्हें ताकि आप "अमान्य" समूह नामों के लिए भी बिंदीदार संकेतन का उपयोग कर सकें। के लिये
उदाहरण:

आपकी सूची में foo-bar.xyz नाम का एक समूह है। अब आप लिखना चाहते हैं
एक टेम्प्लेट जो उस समूह से संबंधित मेजबानों की सूची बनाता है:

{% समूहों में होस्ट के लिए['foo-bar.xyz'] %}
{{ मेज़बान }}
{% अंत%}

ध्यान रखें कि टेम्पलेट का यह संस्करण काम नहीं करेगा:

{% समूहों में होस्ट के लिए.foo-bar.xyz%}
{{ मेज़बान }}
{% अंत%}

ऐसा इसलिए है क्योंकि - और . इस मामले में विशेष अर्थ है। NS
बिंदीदार अंकन हालांकि पूरी तरह से ठीक होगा यदि आपके समूह के पास होगा
नाम foo_bar_xyz क्योंकि टेम्पलेट तब बन जाता है:

{% समूहों में होस्ट के लिए.foo_bar_xyz%}
{{ मेज़बान }}
{% अंत%}

जो बिल्कुल ठीक है।

उपयोगकर्ताओं के लिए चीजों को आसान बनाने के प्रयास में, Ansible जाहिरा तौर पर हमेशा
समूह के नाम के लिए कुछ स्वच्छता किया। इसका मतलब यह था (और 2.10 . तक)
अभी भी है) उपरोक्त उदाहरणों में foo_bar_xyz का उपयोग करना संभव है, भले ही
समूह को वास्तव में foo-bar.xyz कहा जाता है। व्यक्तिगत रूप से मुझे यह नहीं लगता
चीजों को बिल्कुल आसान बनाता है और ऐसा लगता है कि कोर टीम भी अब सहमत है
उस के साथ।
इसलिए इस मुद्दे से निपटने का उनका अगला प्रयास इसे असंभव बनाना है
पहले स्थान पर "अमान्य" समूह के नाम। हालाँकि जहाँ तक मैं इसे समझता हूँ
Force_valid_group_names . सेट करके इस सीमा से बाहर निकलना हमेशा संभव होगा
= अनदेखा करें।

लंबी कहानी संक्षेप में यह वास्तव में दो अलग-अलग बदलाव हैं जो कि रहे हैं
आपस में जुड़े हुए [1]। जहां से भ्रमित करने वाला नाम और शब्द
चेतावनी।

फिर से मैं इस मुद्दे को कैसे समझता हूं। कृपया मुझे सुधारें अगर मैं हूँ
गलत!

[1] अधिक जानकारी के लिए देखें RFC1925
http://www.faqs.org/rfcs/rfc1925.html पैराग्राफ 2, बिंदु (5)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/ansible/ansible/issues/56930?email_source=notifications&email_token=AA5N2CJCIELW7JWHC6OJ35DQEQHSPA5CNFSM4HPRGLKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN27PORZ4Z521KN#IZGOD4-5K
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA5N2CIVT5PLD2QCAGGBK6LQEQHSPANCNFSM4HPRGLKA
.

मेरी ईमानदार राय में यह वास्तव में एक गलत निर्णय है। और गलत कारण से। समर्थन अनुरोधों की संख्या को कम करना, वास्तव में?

Ansible, एक उपकरण के रूप में, अंतिम उपयोगकर्ता पर भाषा विशिष्ट विवरण नहीं थोपना चाहिए। मैं पहले से ही इतना परेशान हूं कि टेराफॉर्म ने मुझे गले के नीचे गोलांग लगा दिया, अब यहां वही हो रहा है जो Ansible और "पायथनिक" शैली के साथ हो रहा है। मुझे गलत मत समझो, मैं गो और पायथन दोनों के साथ काफी अच्छा काम करता हूं, लेकिन जब कोड के रूप में बुनियादी ढांचे की बात आती है, तो मुझे इसकी परवाह क्यों करनी चाहिए? और YAML के प्रबंधन के लिए कोड आधार के आकार को निर्धारित करने के वादे के साथ क्या हुआ? "डेटा के रूप में बुनियादी ढांचा, जिसे आप पढ़ और चला सकते हैं", मैंने ऐसा कई बार सुना ... जहां तक ​​मुझे पता है, YAML डैश और अंडरस्कोर दोनों की बिल्कुल भी परवाह नहीं करता है।

BTW, अंडरस्कोर का समर्थन नहीं करने वाली बहुत सी चीजें हैं। होस्टनाम, एडब्ल्यूएस क्षेत्र और आईडी वस्तुतः सब कुछ के लिए, बस कुछ महत्वपूर्ण लोगों का उल्लेख करने के लिए। उन सभी अपवादों को बनाए रखने के लिए शुभकामनाएँ जहाँ परिवर्तन नहीं होना चाहिए ...

यहां आने वाले लोगों के लिए इसे दूर करने के लिए एक त्वरित समाधान की तलाश में, बस force_valid_group_names = ignore को अपने ansible.cfg और खुश रहें।

मेरी समझ यह है कि आप वैसे भी रिक्त स्थान वाले चर के लिए डॉट नोटेशन का उपयोग नहीं कर सकते हैं, और जब मैं रिक्त स्थान के साथ चर कभी नहीं बनाता हूं, दुर्भाग्य से बहुत सारे विक्रेता हैं जो जेसन एपीआई प्रतिक्रियाओं के माध्यम से रिक्त स्थान के साथ शब्दकोश कुंजी लौटाते हैं। मेरे लिए समझदार विकल्प स्क्वायर ब्रैकेट नोटेशन पर स्विच करना प्रतीत होता है। उम्मीद है कि force_valid_group_names को अनदेखा करने के लिए सेट करने से सड़क पर और बुरे प्रभाव नहीं पड़ते, कौन जानता है कि इस बदलाव के साथ भविष्य में और क्या योजना बनाई गई है।

यह एक बहुत ही भयानक निर्णय है, खासकर जब ओपनस्टैक (और एडब्ल्यूएस) के साथ गतिशील सूची के साथ काम करने की बात आती है।
"निषिद्ध वर्ण" वाले इंस्टेंस नाम और मेटाडेटा कुंजियां अक्सर अंतर्निहित क्लाउड से इन्वेंट्री आइटम और/या समूह चर के रूप में लौटा दी जाती हैं। यह बहुत सारे ओपनस्टैक (और एडब्ल्यूएस) व्यवस्थापकों के लिए जीवन नरक बनाने जा रहा है जो मेटा टैग और या इंस्टेंस आईडी का उपयोग करके अपने बेड़े का प्रबंधन करने की कोशिश कर रहे हैं:
उदाहरण-8ca09c33-f255-440f-9544-b0ab318c79d9
मेटा-ओएस_उबंटू

उत्तरदायी देवों को @geerlingguy की राय को गंभीरता से लेना चाहिए। वह Ansible Galaxy के सबसे बड़े योगदानकर्ताओं में से एक है और उसकी भूमिकाओं को बहुत से लोग खाते हैं। मुझे लगता है कि यह परिवर्तन उन लोगों के लिए वास्तव में बुरा है जिनके नाम के हजारों होस्ट हैं: $env-$role-[0..99] । क्या हमें अपने उत्तरदायी अधिपतियों को खुश करने के लिए हर चीज का नाम बदलना चाहिए?

@ssbarnea एक बात के लिए, हम केवल चर नामों और अन्य समान कुंजियों को अनुमति देने के लिए एक धक्का दे रहे हैं, जो कि मान्य अजगर पहचानकर्ता हैं। समूह नामों के बारे में थोड़ा और समझाने के लिए, यह "डॉट सिंटैक्स" जैसे groups.foo-group का उपयोग करने का प्रयास करने वाले उपयोगकर्ताओं के लिए एक समस्या का कारण बनता है, जो उपयोगकर्ता की अपेक्षा नहीं करता है। इस तरह की छोटी समस्याओं के कारण होने वाली समस्याओं और समर्थन अनुरोधों की संख्या ने हमें सुरक्षित गार्ड नामों के रास्ते पर जाने के लिए प्रेरित किया है ताकि यह सुनिश्चित हो सके कि इस तरह की समस्याएं न हों।

उन लोगों के लिए जिन्हें हम अमान्य वर्ण मानते हैं, इस कार्यक्षमता से बाहर निकल सकते हैं।

कब तक उपयोगकर्ताओं को इस व्यवहार से बाहर निकलने की अनुमति दी जाएगी? क्या आगे बढ़ने वाले सभी उत्तरदायी संस्करणों में इस व्यवहार को अक्षम करने के लिए एक स्थायी कॉन्फ़िगरेशन विकल्प होगा, या यह केवल 2.11 तक समर्थित होगा? मुझे डिफ़ॉल्ट रूप से चालू होने वाले विकल्प के लिए खुशी होगी, जब तक कि मेरे पास हमेशा इसे बंद करने का विकल्प होता है।

यदि यह 2.11+ में एक कठिन प्रतिबंध बन जाता है, तो आप अपने आप को ऐसे ग्राहकों को खोते हुए पाएंगे जो उनके संगठन की बाधाओं से बंधे हैं (सभी उत्तरदायी उपयोगकर्ताओं के पास उनकी कंपनी द्वारा उपयोग किए जाने वाले नामकरण सम्मेलनों को निर्धारित करने की शक्ति नहीं है)। ऐसा लगता है कि यह परिवर्तन उन लोगों के लिए भी एक महत्वपूर्ण चुनौती पेश करेगा जो क्लाउड इन्फ्रास्ट्रक्चर का प्रबंधन करने के लिए उत्तरदायी हैं, जहां डैश का अत्यधिक उपयोग किया जाता है।

सिर्फ उन लोगों को याद दिलाने के लिए जिन्होंने यहां पूरा धागा नहीं पढ़ा है। डेवेल मेलिंग सूची पर एक सूत्र भी है: https://groups.google.com/forum/#!topic/ansible -devel/bjAcM9ferIw

आईएमएचओ यह परिवर्तन वास्तव में खराब विकल्प था। मामूली रिलीज़ संस्करणों में कोडब्रेकिंग सिंटैक्स परिवर्तन हमें अपने वातावरण में Ansible के उपयोग को विस्तारित करने से रोकता है। क्योंकि जब यह मेरे उपयोगकर्ताओं की प्लेबुक को तोड़ता है तो मैं Ansible को अपडेट नहीं कर पाऊंगा।

लेकिन जैसा कि @bcoca ने ऊपर कहा है, अधिकांश डेवलपर्स इन चर्चाओं को यहां नियमित आधार पर नहीं देखते हैं और यह मुद्दा बदलाव पर चर्चा करने के लिए सही जगह नहीं हो सकता है क्योंकि यह सही दस्तावेज के बारे में है।

@Tronde : कोई यह तर्क देगा कि प्रभाव को समझने के लिए कहानियों को लिखे जाने से पहले योगदानकर्ताओं और ग्राहकों से परामर्श किया जाता है और किसी के समाधान को कोड करने से पहले अच्छी तरह से प्रतिक्रिया एकत्र की जाती है। जैसा कि यहां कई लोगों ने उल्लेख किया है, यह एक उत्पाद एमजीएमटी विफल है जिसे हमने एक से अधिक बार देखा है।

स्थिति के एक उदाहरण के रूप में @andyfeller इस परिवर्तन के बारे में वर्णन करता है:

हमें अपनी साइट पर इससे समस्या है।

हम Red Hat पहचान प्रबंधक का उपयोग बाहरी वस्तु-सूची के रूप में करते हैं, हम इसे नियंत्रित नहीं करते हैं, इसमें अंडरस्कोर के बजाय डैश के साथ कई होस्ट समूह शामिल हैं। यह नहीं बदला जाएगा (क्योंकि उन नामों का उपयोग करने वाली अन्य सभी चीजें मौजूद हैं)।

तो, हमें चाहिए:

• वर्तमान व्यवहार को बनाए रखने के लिए Ansible को कॉन्फ़िगर करने के लिए
• बहिष्करण चेतावनी को शांत करें
• कमांड लाइन Ansible और Ansible Tower के लिए ऐसा करें

एफवाईआई पीआर https://github.com/ansible/ansible/pull/66650 (कृपया वहां कोई पिचफोर्क नहीं है) 2.10 (वर्तमान क्षण के अनुसार) के लिए निर्धारित है, जिसका अर्थ है कि जो कोई भी वर्तमान में इस चेतावनी को देखता है (एक बार जब वे 2.10 में अपग्रेड हो जाते हैं, फिर से यह मानते हुए कि पीआर विलय हो गया है) इसके बजाय प्लेबुक विफलताओं को शुरू करना शुरू करें (जब तक कि वे force_valid_group_names = ignore को ansible.cfg )।

केवल दृश्यता के लिए पोस्टिंग। मैं अभी भी अपने पहले के दावे के पीछे दृढ़ता से हूं कि यह एक उपयोगकर्ता-शत्रुतापूर्ण डिफ़ॉल्ट है, क्योंकि अभी भी कई गतिशील इन्वेंट्री स्क्रिप्ट हैं (अंसिबल का कुछ हिस्सा या अब 'आधिकारिक-ईश' संग्रह में स्थानांतरित हो गया है) जो डैश के साथ समूह नाम उत्पन्न करते हैं या अन्य मान्य DNS वर्ण।

व्यावहारिक रूप से जो कोई भी AWS के साथ Ansible का उपयोग करता है, उसे डिफ़ॉल्ट को ओवरराइड करना होगा।

@geerlingguy क्या यह सही पीआर # है? ऐसा लगता है कि यह इस मुद्दे की ओर इशारा करता है।

FYI करें इस पर 19:06:55 . से शुरू होने वाली थी

@apple4ever उफ़, लिंक को अपडेट किया, यह https://github.com/ansible/ansible/pull/66650 है

इसलिए मैंने उन चीजों की कई टिप्पणियों के ऊपर देखा है जिनका पहले से ही उत्तर/डिबंक/आदि था, इसलिए बस यहां मेरी पिछली पोस्ट को लिंक करने जा रहा हूं।

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

कृपया ऐसी नई पोस्ट न जोड़ें जो चर्चा के लिए नए आइटम न जोड़ें क्योंकि वे पिछली पोस्ट को छिपाते हैं जिनका पहले ही उत्तर दिया जा चुका था।

वैसे, पाइथन दस्तावेज़ में लिंक करने के लिए एक अच्छी जगह कहां होगी कि वैध चर नाम कैसा दिखता है? https://docs.python.org/3/reference/lexical_analysis.html#grammar -token-identifier है, लेकिन यह कंप्यूटर विज्ञान पृष्ठभूमि वाले लोगों के लिए वास्तव में उपयोगकर्ता के अनुकूल या पठनीय नहीं है।

पूछने का कारण यह है कि मुझे यकीन नहीं है कि वास्तविक प्रारंभिक शिकायत का वास्तव में निपटारा किया गया है या नहीं। केवल एक चेतावनी है कि कुछ गड़बड़ है, लेकिन यह पता लगाने के लिए बहुत खुदाई की जाती है कि वास्तव में क्या और कैसे - यदि इच्छुक या सक्षम - वास्तव में एक वैध समूह नाम चुन सकता है। मैं कम से कम एक स्पष्ट "समूह नाम foo-bar में अमान्य वर्ण ( - ) की अपेक्षा करता हूं। मान्य समूह नाम मान्य पायथन पहचानकर्ता होने चाहिए (अधिक जानकारी के लिए https://docs.python.org/??? देखें)" संदेश, न केवल "खराब वर्ण हैं, वास्तव में पता लगाने के लिए -vvvv के साथ फिर से जांचें!"। आदर्श रूप से यह भी उल्लेख करेगा कि इसे अक्षम किया जा सकता है, लेकिन इससे अन्य अप्रत्याशित समस्याएं हो सकती हैं (जैसे कि Ansible के लिए समूहों को अलग करना वास्तव में कठिन बनाना foo-bar , foo.bar और foo_bar )

वर्तमान में यह "आपने कुछ गलत किया, इसे ठीक करें" संदेश से अधिक है, जिसमें कोई स्पष्ट तरीका नहीं बताया गया है कि कैसे आगे बढ़ना है, जिसने यहां मजबूत प्रतिक्रिया में योगदान दिया हो।

@geerlingguy ने टिप्पणी 56930 में लिखा:

(जब तक वे एक ansible.cfg में force_valid_group_names = false सेट नहीं करते हैं)

दस्तावेज़ीकरण इस कुंजी के लिए मान्य मान के रूप में 'गलत' का उल्लेख नहीं करता है। मैंने मान को 'अनदेखा' करने के लिए सेट किया है जो चाल चलाना चाहिए। लेकिन क्या 'गलत' एक अमान्य कीवर्ड है या यह सही है और यहां दस्तावेज़ीकरण पूरा नहीं हुआ है?

@bcoca पिछली टिप्पणी में:

बस एक बार यह स्पष्ट रूप से कहने के लिए, आप हमेशा समूह नामों में डैश का उपयोग करने में सक्षम होंगे, डॉट्स और अन्य वर्ण जिन्हें अब 'अमान्य' माना जाता है, बस डिफ़ॉल्ट रूप से नहीं। यह 'डिफ़ॉल्ट' है जिसे बहिष्कृत किया जा रहा है, डिफ़ॉल्ट 2.11 में 'सुरक्षित' होगा, लेकिन आपके पास हमेशा पुराने व्यवहार को 'ऑप्ट इन' करने का विकल्प होगा।

आपने बार-बार कहा है कि वर्तमान व्यवहार को संरक्षित किया जा सकता है, लेकिन यह _now_ करने के लिए सटीक ansible.cfg सेटिंग्स क्या हैं और बहिष्करण चेतावनी को कुचल दें।

मैंने कोशिश की है जैसा कि @geerlingguy ने टिप्पणी 56930 में लिखा है:

(जब तक वे एक ansible.cfg में force_valid_group_names = false सेट नहीं करते हैं)

जिसके कारण मेरी प्लेबुक विफल हो जाती है, जब उसे हाइफ़न वाले होस्ट या समूह नहीं मिलते हैं (वे एक इन्वेंट्री प्लगइन से आ रहे हैं जिसे हमने BTW लिखा है, क्या थीसिस को ट्रांसफ़ॉर्म भी करना है, या ऐसा तब किया जाता है जब Ansible से इन्वेंट्री को निगला जाता है) प्लगइन?)

मैंने कोशिश की है जैसा कि @geerlingguy ने टिप्पणी 56930 में लिखा है:

(जब तक वे एक ansible.cfg में force_valid_group_names = false सेट नहीं करते हैं)

जिसके कारण मेरी प्लेबुक विफल हो जाती है, जब उसे हाइफ़न वाले होस्ट या समूह नहीं मिलते हैं (वे एक इन्वेंट्री प्लगइन से आ रहे हैं जिसे हमने BTW लिखा है, क्या थीसिस को ट्रांसफ़ॉर्म भी करना है, या ऐसा तब किया जाता है जब Ansible से इन्वेंट्री को निगला जाता है) प्लगइन?)

यह कई टिप्पणियों में उल्लेख किया गया था और दस्तावेज़ीकरण में है । आपको कभी भी उपयोग अनदेखा करना चाहिए।

तो क्या हमें अब EC2 डायनेमिक इन्वेंट्री स्क्रिप्ट का उपयोग नहीं करना चाहिए क्योंकि यह सब कुछ 'us-east-1', 'us-east-2', आदि द्वारा समूहित करता है? या इसे अपडेट करने की कोई योजना है? मैं अभी EC2 डायनेमिक इन्वेंट्री स्क्रिप्ट के लिए Ansible के दस्तावेज़ में गया था और इसे Github पर डाउनलोड करने का लिंक अब काम नहीं करता है, इसलिए यह दिलचस्प है।

मैं अभी EC2 डायनेमिक इन्वेंट्री स्क्रिप्ट के लिए Ansible के दस्तावेज़ में गया था और इसे Github पर डाउनलोड करने का लिंक अब काम नहीं करता है, इसलिए यह दिलचस्प है।

देखें https://github.com/ansible/ansible/issues/68419

आप में से उन लोगों के लिए जो आईआरसी लॉग पढ़ने की जहमत नहीं उठाते, यहां निर्णय है, अर्थात कोई निर्णय नहीं:

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

हाँ, किसी ने लिखा "एमएल या आईआरसी द्वारा ड्रॉप करने के लिए स्वतंत्र महसूस करें"। नहीं, "यह परियोजना लोकतंत्र नहीं है"।

हाँ, किसी ने लिखा "एमएल या आईआरसी द्वारा ड्रॉप करने के लिए स्वतंत्र महसूस करें"। नहीं, "यह परियोजना लोकतंत्र नहीं है"।

ईमानदार होने के लिए यह ओपनसोर्स के साथ गलत है - अगर यह लोकप्रिय तरीके से नहीं जाता है - लोग इसे फोर्क कर सकते हैं, क्या इसे फोर्क किया जा सकता है?

मैं देख सकता हूं कि पीआर को उत्तर में स्वीकार करना बहुत धीमा है। पैच स्पष्ट रूप से आवश्यक और सरल परिवर्तन दिखते हैं लेकिन यह कभी भी अंदर नहीं आता है। सौभाग्य से उत्तरदायी लोगों को कस्टम प्लगइन्स का उपयोग करने की अनुमति देने के लिए लचीला है, हालांकि ऐसा लगता है कि पुराना योगदान में खुद को कम कर देगा - या ऐसा करने में और भी परेशानी होगी।

थोड़ा उदास लग रहा है, सच में...

@ sunshine69 मुझे आपका दर्द महसूस होता है। लेकिन यह एक ऐसी चर्चा है जो IRC या Google Group for Ansible Development पर होनी चाहिए।

यह मुद्दा इसके लिए सही जगह नहीं है। क्योंकि यहां बहुत कम लोग पढ़ते हैं।

@ sunshine69 मुझे आपका दर्द महसूस होता है। लेकिन यह एक ऐसी चर्चा है जो IRC या Google Group for Ansible Development पर होनी चाहिए।

यह मुद्दा इसके लिए सही जगह नहीं है। क्योंकि यहां बहुत कम लोग पढ़ते हैं।

हालांकि उन अन्य चैनलों में चर्चा अधिक उत्पादक हो सकती है, विशेष रूप से इस मुद्दे का अनुसरण करने वाले लोगों के लिए पारदर्शिता की सराहना की जाती है। आईआरसी आखिरकार हर किसी की पसंद नहीं है।

FYI करें: TRANSFORM_INVALID_GROUP_CHARS के लिए बहिष्करण निकालें कल ही मर्ज किया गया था। 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 को धन्यवाद! आप ही हैं जो ansible को बेहतर बना रहे हैं।

मैं बाउंस (प्रारंभ/बंद) के लिए हमारे आवेदन के लिए काम कर रहा हूं लेकिन मैं एप्लिकेशन होस्ट से जुड़ा नहीं हूं।

मैंने पिंग कमांड की कोशिश की, जिसे आपने भेजा और यह काम करता है ...

[ webadmin@vlodjumpts00 ~]$ पिंग 8.8.8.8

पिंग 8.8.8.8 (8.8.8.8) 56(84) डेटा के बाइट्स।

8.8.8.8 से 64 बाइट्स: icmp_seq=1 ttl=112 समय=10.6 ms

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

-बैश: Mirrorlist.centos.org: आदेश नहीं मिला

मैं इसे अपने संगठन के लिए उपयोग करना चाहता हूं .. अगर मैं "ansible all -m ping" कमांड चलाता हूं। त्रुटि का सामना करना पड़ रहा है, नीचे विवरण है:

[आ 63457@vlodjumpts00 बिन]$ सभी-एम पिंग

बदलें, लेकिन फिर भी बहिष्करण पर उपयोगकर्ता को कॉन्फ़िगर करने योग्य हो। यह सुविधा संस्करण 2.10 में हटा दी जाएगी। बहिष्करण चेतावनियां हो सकती हैं

deprecation_warnings=False in ansible.cfg सेट करके अक्षम किया गया।

RTE3EPएडमिन | पहुंच से बाहर! => {

"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"

}

कृपया मेरी मदद करें... मुझे यह करने की क्या आवश्यकता है। वास्तव में, हमारे पास होस्ट मशीन को जोड़ने के लिए होस्ट फ़ाइल के लिए UN/PWD नहीं है।

लोकलहोस्ट ansible_connection = लोकल

[आरटीई3वीएफओ]

RTE3VFOव्यवस्थापक ansible_host=vlddwblasts001.test.intranet

RTE3VFOप्रबंधित ansible_host=vlddwblasts002.test.intranet

[आरटीई3ईपी]

RTE3EPव्यवस्थापक ansible_host=vlddwblasts002.test.intranet

RTE3EPप्रबंधित ansible_host=vlddwblasts003.test.intranet

[आरटीई3आरईएस]

RTE3RESएडमिन ansible_host=vlddwblasts003.test.intranet

RTE3RESAप्रबंधित ansible_host=vlddwblasts004.test.intranet

[RTE3ORCH]

RTE3ORCHव्यवस्थापक ansible_host=vlddwblasts004.test.intranet

RTE3ORCHप्रबंधित ansible_host=vlddwblasts005.test.intranet

[आरटीई3ईएएसई]

RTE3EASEव्यवस्थापक ansible_host=vlddwblasts005.test.intranet

RTE3EASEप्रबंधित ansible_host=vlddwblasts006.test.intranet

[आरटीई3आरटीएस]

RTE3RTSव्यवस्थापक ansibke_host=vlddwblasts006.test.intranet

[ईज़ी-एएसआर-टेस्ट 2: बच्चे]

आरटीई3वीएफओ

आरटीई3ईपी

आरटीई3आरईएस

RTE3ORCH

RTE3EASE

RTE3RTS

और निर्देशिका संरचना है:

[ webadmin@vlodjumpts00 ansible]$ pwd

/आदि/उत्तरदायी

[ webadmin@vlodjumpts00 ansible]$ ll

कुल 84

-आरडब्ल्यू -------- 1 वेबएडमिन वेबएडमिन 607 जुलाई 12 2017 1

-rw-r--r-- 1 वेबएडमिन वेबएडमिन 17910 सितंबर 19 09:55 ansible.cfg

-rw-r--r-- 1 रूट रूट 19985 Dec 8 2019 ansible.cfg.rpmnew

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

-rwxr-xr-x 1 वेबएडमिन वेबएडमिन 1034 सितंबर 19 09:16 ईज़ी-होस्ट

-rwxr-xr-x 1 वेबएडमिन वेबएडमिन 1647 सितंबर 19 10:50 मेजबान

-rw---------- 1 webadmin webadmin 2679 Jul 3 2017 host.bkp

-आरडब्ल्यू -------- 1 वेबएडमिन वेबएडमिन 273 जुलाई 6 2017 लाइनइन्सफाइल_tst.yml

drwx------ 4 webadmin webadmin 4096 Nov 2 2017 playbooks

drwxr-xr-x 3 रूट रूट 19 दिसंबर 8 2019 भूमिकाएं

-rwxr-xr-x 1 वेबएडमिन वेबएडमिन 7321 नवंबर 2 2017 servmix_hosts

-आरडब्ल्यू -------- 1 वेबएडमिन वेबएडमिन 208 सितंबर 19 10:55 टेस्ट.वाईएमएल

-आरडब्ल्यू -------- 1 वेबएडमिन वेबएडमिन 122 सितंबर 19 10:54 vars.yaml

हम सीधे होस्ट से कनेक्ट नहीं हैं... पहले हमारे जंप सर्वर में लॉग इन करें और ssh होस्ट से...

जंप सर्वर "vmdcltctws217" पोर्ट का उपयोग कर रहा है = 22, कनेक्शन प्रकार = ssh

और फिर हमारे UN/PWD के साथ दर्ज करें

उसके बाद हमने होस्ट सर्वर से कनेक्शन के लिए sudo किया ..

सुडो सु - आसान

और फिर ssh होस्ट सर्वर जैसे ..

vlddwblasts001.test.intranet

फिर हम यहां से स्टार्ट/स्टॉप कमांड चलाते हैं..

कृपया मेरी मदद करें, मैं इसके लिए क्या कर सकता हूं?