Cp-ansible: उत्तरदायी गैलेक्सी समर्थन

उस पर कोई अपडेट? इन प्लेबुक का उपयोग करना बहुत आसान हो जाएगा

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

सामान्य अपेक्षा रेपो को क्लोन करना है, और फिर दिए गए सेटअप के लिए आवश्यक प्लेबुक चलाना है।

Ansible 2.9 ने कलेक्शंस नामक एक नया वितरण प्रारूप पेश किया। ऐसा लगता है कि यह इस मुद्दे को हल करने के लिए बेहतर फिट है क्योंकि संग्रह में प्लेबुक, भूमिकाएं, मॉड्यूल और प्लगइन्स शामिल हो सकते हैं।

कुछ संकेत:

• https://www.ansible.com/blog/getting-started-with-ansible-collections
• https://docs.ansible.com/ansible/latest/user_guide/collections_using.html
• https://docs.ansible.com/ansible/latest/dev_guide/developing_collections.html

मैंने आकाशगंगा संग्रह के रूप में पुनर्गठन पर एक स्टैब लिया, all.yml प्लेबुक और कुछ अधिकतर बुनियादी कॉन्फ़िगरेशन (एसएसएल और एसएसएल/सादा श्रोताओं) के साथ काम करने का परीक्षण किया। इसके कुछ हिस्से बहुत भद्दे हैं, मुख्य रूप से जहां तक ​​​​मैं किसी भी फिल्टर और मॉड्यूल को संदर्भित करने के लिए कह सकता हूं, आपको संपूर्ण आकाशगंगा नामस्थान का संदर्भ देना होगा। हालांकि यह मेरे उपयोग के मामले के लिए काम करता है, और अगर टीम को लगता है कि यह जोड़ने लायक है तो मुझे पीआर खोलने में खुशी हो रही है।

https://github.com/aig787/cp-ansible/tree/agriffin/5.4.1-repack

@ aig787 मुझे यह पसंद है! मैंने हमेशा महसूस किया है कि अपग्रेड प्लेबुक एक "प्लेबुक" निर्देशिका में होनी चाहिए
भूमिकाओं के पास प्लगइन्स में क्या है, सही है?
क्या confluentinc_cp dir भी आवश्यक है?

एक मुश्किल टुकड़ा ansible.cfg है, मुझे हमेशा प्लेबुक के ठीक बगल में रखना पसंद है, क्योंकि इसके लिए आवश्यक है कि उस फ़ाइल में ansible कॉन्फिगरेशन इंस्टॉल के दौरान उपयोग किया जाए

सभी भूमिकाओं के पास प्लगइन्स dir (https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#plugins-directory) में मौजूद चीज़ों तक पहुंच होती है। मुझे लगता है कि आपको इसे एक्सेस करने के लिए केवल पूरे नाम का उपयोग करना होगा, उदाहरण के लिए मुझे KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}" को KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}" बदलना पड़ा ताकि फ़िल्टर मेरे लिए काम कर सके। इसके आसपास कोई रास्ता हो सकता है लेकिन मैं इसे ढूंढ नहीं पाया।

बस confluentinc_cp निर्देशिका को हटाने की कोशिश की और यह ठीक काम किया, इसलिए मुझे लगता है कि यह आवश्यक नहीं है। मैंने शुरुआत में इसे ansible-galaxy collection init साथ बूटस्ट्रैप किया और बनाई गई संरचना के साथ चला गया।

क्या कोई कारण है कि ansible.cfg को बाकी के साथ प्लेबुक निर्देशिका में नहीं ले जाया जा सकता है? मैं _थिंक_ करता हूं कि प्लेबुक का उपयोग करने के लिए लोगों को अभी भी रेपो को क्लोन करने और चलाने की आवश्यकता होगी जैसा कि वे अभी करते हैं। इसे आकाशगंगा में रखने का लाभ लोगों को प्लेबुक को आसान बनाने के बजाय अपने स्वयं के सेटअप में भूमिकाओं तक पहुंच प्रदान करना होगा। वैसे भी यह मेरा 2 सेंट है।

मुझे व्यक्तिगत रूप से परवाह नहीं है कि ansible.cfg कहाँ रखा गया है, मुझे बस यह पता है कि यदि आप प्लेबुक चलाते हैं और आपका वर्तमान dir वह नहीं है जहाँ ansible.cfg है तो समस्याएँ हैं।

मैं उत्तरदायी सर्वोत्तम प्रथाओं का पालन करने और संग्रह निर्देशिका संरचना का पालन करने का मूल्य देख सकता हूं, लेकिन मैं उत्सुक हूं कि इस संग्रह को आकाशगंगा में प्रकाशित करने से हमें क्या लाभ होता है। अधिक दृश्यता?

मेरे लिए यह आकाशगंगा और हमारी शाखाओं में संस्करण का प्रबंधन करने के लिए बहुत अधिक उपरि की तरह लगता है।

यह लाभ के उपयोग में आसानी होगी। अगर मेरे पास एक प्लेबुक है जो मेरे सभी नोड्स के लिए कुछ आधार कॉन्फ़िगरेशन करता है तो मैं इसे एक आवश्यकता फ़ाइल में जोड़ सकता हूं और `ansible-galaxy install -r आवश्यकताओं.yml' चला सकता हूं और क्लोन करने के बजाय मेरी मौजूदा प्लेबुक में काफ्का भूमिका का संदर्भ देता हूं रेपो और प्लेबुक का विस्तार करें या भूमिका निर्देशिकाओं की प्रतिलिपि बनाएँ।

आपको वास्तव में इसे क्यों प्रकाशित करना है, मुझे विश्वास नहीं है कि संग्रह git संदर्भों का समर्थन करते हैं जैसे भूमिकाएं करते हैं (https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a -फाइल बनाम https://docs.ansible.com/ansible/latest/user_guide/collections_using.html#install-multiple-collections-with-a-requirements-file)। मैं संस्करण के लिए ओवरहेड की मात्रा के बारे में सहमत हूं, यह थोड़ा भारी लगता है।

मुझे व्यक्तिगत रूप से इसकी परवाह नहीं है कि यह गैलेक्सी में है या नहीं, लेकिन, एक आवश्यकता फ़ाइल में विभिन्न भूमिकाओं को आसानी से संदर्भित करने में सक्षम होने के कारण वास्तव में सराहना की जाएगी: मुस्कान:

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

मैं इस भंडार में भूमिकाओं का उपयोग करना चाहता हूं, लेकिन मैं उन्हें अपनी कस्टम भूमिकाओं (भूमिका विस्तार) में भूमिका निर्भरताओं के रूप में उपयोग करना चाहता हूं। हमने प्लेबुक (all.yml) का उपयोग करना शुरू कर दिया था, लेकिन हमारे एक्सटेंशन को सही समय के साथ लागू करने में बहुत परेशानी हुई। इस दृष्टिकोण के साथ मेरा पहला (अवरुद्ध) मुद्दा https://github.com/confluentinc/cp-ansible/pull/442 के साथ तय किया गया था

[DEPRECATION WARNING]: Included file 
'/builds/kafka/provisioner/tasks/failure_handling.yml' not found, however since
 this include is not explicitly marked as 'static: yes', we will try and 
include it dynamically later. In the future, this will be an error unless 
'static: no' is used on the include task. If you do not want missing includes 
to be considered dynamic, use 'static: yes' on the include or set the global 
ansible.cfg options to make all includes static for tasks and/or handlers. This
 feature will be removed from ansible-base in version 2.12. Deprecation 
warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

विवरण को देखते हुए, मुझे लगता है कि सामान्य समस्या यह है कि भूमिकाएं वर्तमान में स्वयं निहित नहीं हैं। इसे ठीक करना अंततः Ansible Galaxy में भूमिकाओं या भूमिका-संग्रह को प्रकाशित करने की दिशा में एक अनिवार्य कदम होगा। और मुझे लगता है कि यह काफी आसानी से तय किया जा सकता है, क्योंकि यह भूमिकाओं के भीतर से निम्नलिखित शीर्ष-स्तरीय निर्देशिका /filter_plugins और /tasks संदर्भ में उबलता है।

पुल अनुरोध के रूप में आप निम्नलिखित कार्यों के बारे में क्या सोचते हैं:

1. /filter_plugins फ़ोल्डर को confluent.variables भूमिका में ले जाएँ - क्या यह उस भूमिका का हिस्सा है? फ़िल्टर प्लग इन कम से कम इस भूमिका में उपयोग में हैं।

2. पुन: प्रयोज्य कार्यों-फ़ाइलों को /tasks में मौजूदा भूमिकाओं में से एक में स्थानांतरित करें, शायद confluent.common मौजूदा भूमिकाओं के लिए सबसे उपयुक्त है, या उनके लिए एक नई समर्पित भूमिका बनाना ( confluent.common_tasks )? और शामिल_रोल#tasks_from के साथ पुन: उपयोग किए गए कार्यों-फ़ाइलों के संदर्भों को अपडेट करें। उदाहरण:

Index: roles/confluent.zookeeper/tasks/health_check.yml
<+>UTF-8
===================================================================
--- roles/confluent.zookeeper/tasks/health_check.yml    (revision 0d369ae20c8215dd2ec469f269dc804539f58190)
+++ roles/confluent.zookeeper/tasks/health_check.yml    (date 1602793473938)
@@ -25,7 +25,9 @@
   ignore_errors: true

 - name: Fetch Files for Debugging Failure
-  include: tasks/failure_handling.yml
+  include_role:
+    name: confluent.common
+    tasks_from: failure_handling.yml
   vars:
     service_name: "{{zookeeper_service_name}}"
     config_file: "{{zookeeper.config_file}}"

@erikgb यह कुछ ऐसा है जिस पर हमने अतीत में आंतरिक रूप से चर्चा की है। विशेष रूप से, स्वयं निहित भूमिकाओं, बनाम कोड के दोहराव को कम करने के बारे में काफी चर्चा हुई। ऐसा लगता है कि हमें इसे 2.12.1 के लिए बदलना होगा। चेतावनी के आधार पर, Ansible का विमोचन, इसलिए मैं सोच रहा हूँ कि /filter_plugins और /tasks को confluent.common भूमिका में ले जाने के लिए सबसे अधिक समझदारी हो सकती है, और फिर उचित उपयोग करें अन्य सभी भूमिकाओं में आयात विवरण।

@domenicbove आपके क्या विचार हैं?

जब तक कार्यक्षमता @erikgb @JumaX के अनुरूप रहती है, तब तक मुझे फ़ाइल स्थानों को स्थानांतरित करने में कोई समस्या नहीं है।
ऐसा लगता है कि यह काफी बड़ा काम है कि इसे मास्टर शाखा में जाना चाहिए, हालांकि हमारी अगली रिलीज को लक्षित करना।

@domenicbove हमारी अगली प्रमुख रिलीज़ के लिए काम करने के बारे में सहमत हुए। @erikgb हम इसे ट्रैक करने के लिए एक आंतरिक JIRA जोड़ेंगे और देखेंगे कि क्या हम इसे अपनी अगली रिलीज़ के लिए रोडमैप पर प्राप्त कर सकते हैं।

या @erikgb यदि आपके पास शाखा में बैठे हुए काम है, तो मास्टर शाखा में पीआर बनाने के लिए आपका स्वागत है और हम समीक्षा करेंगे। मुझे नहीं लगता कि यह इस मुद्दे को पूरी तरह से हल करेगा हालांकि, हमें अभी भी आकाशगंगा बनाने की जरूरत है।

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

@erikgb यह CP 6.1 के लिए होगा, हम नई कार्यक्षमता नहीं डालते हैं, खासकर यदि इसमें पुराने रिलीज में एक प्रमुख रिफैक्टरिंग शामिल है। हमारे पास बहुत से एंटरप्राइज़ ग्राहक हैं जिनकी नीतियां/समस्याएं हैं जब हम मौजूदा संस्करण के लिए रेपो को बहुत अधिक बदलते हैं, तो हम इसे केवल बग फिक्स पर रखने का प्रयास करते हैं।

@domenicbove @JumaX CP 6.1 अधिक समझ में आता है। मैं देखूंगा कि क्या मुझे इस सप्ताह के अंत में पुल अनुरोध (अनुरोधों) पर काम करने के लिए कुछ समय मिलता है। मैं रिफैक्टरिंग को सार्थक भागों में विभाजित करने की सलाह दूंगा। डब्लूडीवाईटी?

@erikgb यदि आप इसे कई पीआर में विभाजित करना चाहते हैं, तो यह मान लेना ठीक है कि प्रत्येक पीआर अभी भी अतिरिक्त पीआर के बिना चलने में सक्षम है। मुझे यकीन नहीं है कि मैंने इसे बहुत अच्छी तरह से कहा है। :)। मास्टर ब्रांच के लिए लक्ष्य बनाना चाहिए।