Packer: -वृंद की तरह-विनाश-पर-त्रुटि

यह उचित लगता है। मुझे लगता है कि -debug ध्वज वास्तव में यहाँ सही दृष्टिकोण है, लेकिन शायद -debug ध्वज को इस तरह के विकल्पों की अनुमति देनी चाहिए:

• हर कदम पर कदम
• एक त्रुटि तक जारी रखें
• सफाई कदम शुरू होने तक जारी रखें

मैं एक त्रुटि तक जारी रखने का विकल्प ढूंढूंगा और vm को अत्यंत उपयोगी नहीं नष्ट करूंगा

अगर कोई मुझे कुछ संकेत दे सकता है, जहां इसे लागू करने की तलाश शुरू करूं तो मैं इसे विकल्प के रूप में जोड़ने में कुछ समय लगा सकता हूं

यह मेरे लिए भी बहुत उपयोगी होगा।

@timmow आपको एक निश्चित फ़्लैग सेट होने पर (उदाहरण के लिए https://github.com/mitchellh/packer/blob/master/builder/amazon/

यह सभी चरणों के माध्यम से कंघी करने के लिए एक निश्चित राशि होगी और यह पता लगाएगी कि कोई कार्रवाई करना कहां तक ​​उचित होगा।

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

अगर मैं किसी भी मदद की पेशकश कर सकता हूं तो मुझे यहां पिंग करने के लिए स्वतंत्र महसूस करें।

fyi जो कि यहां पर पूरी तरह से की गई है https://github.com/mitchellh/multistep/blob/master/basic_runner.go#L71

आपको मूल धावक (debuggable_runner?) का विस्तार करने की आवश्यकता हो सकती है

कुछ प्रकार के चरण "स्किपिंग" कार्यक्षमता को कम करना बहुत अच्छा होगा, जो मूल रूप से इस --no-destroy-on-error प्रकार के कॉन्फ़िगरेशन के लिए क्लीनअप चरणों को छोड़ देगा। यह -debug मोड में कुछ ठंडा सामान भी सक्षम करेगा, जैसे कि s को दबाने के लिए, अंतःक्रियात्मक रूप से।

डिबग "पॉज़िंग" के समान, मुझे लगता है कि -pause-on-error जैसे विकल्प फायदेमंद होंगे।

नमस्ते, मैं देख रहा हूँ कि यह मुद्दा इस कमेटी https://github.com/mitchellh/packer/commit/2ed7c3f65cc2e0a14d39d8934ef1168f8192bb08 द्वारा तय किया गया है, लेकिन मैं मास्टर शाखा के हेड में बदलाव नहीं देखता। यह कहां और क्यों गायब हो गया?

मुझे वास्तव में इसकी भी जरूरत है।

क्या इस सुविधा के होने की कोई उम्मीद है? 2ed7c3f या इसके विलय में कुछ भिन्नता होने के लिए क्या करने की आवश्यकता है?

हाँ, मैं भी इस विकल्प का उपयोग कर सकता हूं। मैं देखता हूं कि यह प्रतिबद्ध था लेकिन फिर गायब हो गया।

क्या इस पर कोई अपडेट है?

मैं वास्तव में इसे भी पसंद करूंगा। मैं आपको यह नहीं बता सकता कि मैंने समस्याओं को डिबग करने के लिए कितना समय बर्बाद किया है और बार-बार त्रुटि के लिए एक लंबी वीएम निर्माण प्रक्रिया से गुजरना पड़ता है। VM को अपने आस-पास रखने में सक्षम होना एक बहुत बड़ी जीत होगी।

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

इस के लिए एक और वोट, -debug विकल्प के रूप में विफलता को दबाता है जिसका मैं विश्लेषण करने की कोशिश कर रहा हूं।

फेल होने से पहले मशीन की अंतिम स्थिति को डिबग करने की कोशिश में इतना समय लगना। -Debug स्विच इसे काटता नहीं है - मैं चाहता हूं कि यह सामान्य प्रक्रिया से चले, फिर विफलता के बाद कार्य फ़ोल्डर को छोड़ दें ताकि मैं लॉग और राज्य के साथ निदान कर सकूं। वास्तव में किसी प्रकार के संरक्षित राज्य स्विच के लिए तत्पर हैं।

इस सुविधा के लिए एक और +1, यह बेहद मददगार होगा।

+1 समान मुद्दों पर चल रहा है, जहां अंतिम स्थिति को डीबग करना अच्छा होगा, कुछ प्रोविजनिंग स्क्रिप्ट्स को ट्विस्ट करें, और फिर बिल्ड को फिर से देखें कि क्या यह प्रक्रिया तय हो गई है, बजाय मैन्युअल रूप से डिबग स्टेप पर प्रवेश करने के बजाय।

इस सुविधा के लिए एक और + 1। यह जानकर अच्छा लगेगा कि यह क्या हुआ? टीम के किसी ने जवाब नहीं दिया। आगे बढ़ें प्लेट तक यह चोट नहीं करता है। जबरदस्त हंसी! मैं पैकर के लिए बिल्कुल नया हूं। मैं 1.5 घंटे के आईएसओ निर्माण के टेल एंड में था और यह हुआ। परीक्षण और डिबगिंग पूरी तरह से मीठा आवेदन पूर्ण धारा लाने के लिए सर्वोपरि होना चाहिए।

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

: +1: मुझे यह फीचर पसंद है

+1 यह सुविधा बहुत अच्छी होगी!

संबंधित या शायद # 1687 द्वारा दोहराया गया

+1 सिर्फ वीएम को छोड़ने में सक्षम होने के लिए क्योंकि यह @error को हटाने के बिना है यह बहुत उपयोगी होगा। हमारी स्थापित स्क्रिप्ट वर्तमान प्रणाली के साथ काफी लंबी, बहुत सी और बहुत सी हैं .. :(

+1 यह बहुत उपयोगी होगा

केवल Packer साथ विफल होने पर डिबग प्रोविज़निंग में मदद करने के लिए +1

+1 मैं उसी नाव में हूं। मैंने विंडोज़ वीएम को फिर से बनाने में अनकहे घंटे बिताए हैं, केवल प्रोविजनिंग चरण में एक बावर्ची त्रुटि है, और वीएम को डीबग करने का कोई तरीका नहीं है जब इसे हटा दिया जाता है। बस कृपया एक विफलता के दौरान सब कुछ नहीं हटाने के लिए एक विकल्प है।

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

Pleeeeeaseeeeeee +1

+1

+1

+1

आश्चर्य है कि इसके लिए तर्क क्या था, यह मुद्दा Google के माध्यम से मिला। जब सुविधा मौजूद नहीं थी, तो उदास हो गए।

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

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

https://github.com/jcoutch/packer

तथ्य यह है कि यह डिफ़ॉल्ट व्यवहार नहीं है, यदि आप मेरी फ्रेंच को माफ कर देंगे, पूरी तरह से पागल है। अपने स्थापित स्क्रिप्ट में एक टाइपो बनाया है? ठीक है, चलो बस सुविधाजनक रूप से _destroy अपने सभी काम करते हैं और कभी भी आपको अपने जीवन के उस घंटे को वापस नहीं देते हैं। ऊपर। और खत्म। फिर।_

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

बिल्कुल चौंका देने वाला।

+1

यार, वह एक भद्दी टिप्पणी थी। खराब मूड कल, लेकिन यह सब समय बर्बाद करना बहुत समय और पैसा खर्च करना शुरू कर रहा है।

@jcoutch - क्या आपके पास एक बिल्ड है जिसे आप साझा कर सकते हैं?

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

बुध पर, 23 सितंबर, 2015, 5:14 अपराह्न रिच जोन्स सूचनाएं @github.com ने लिखा:

यार, वह एक भद्दी टिप्पणी थी। खराब मूड कल, लेकिन यह सब समय
बर्बाद होने में बहुत समय और पैसा खर्च होने लगा है।

@jcouth - क्या आपके पास एक बिल्ड है जिसे आप साझा कर सकते हैं?

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/mitchellh/packer/issues/409#issuecomment -142730452

प्लीज !! : -डॉ

मैं इसे Ansible के साथ चलाने की कोशिश कर रहा हूं लेकिन, यह काम नहीं करता है और KVM अतिथि त्रुटि के बाद चला जाता है, इसलिए, यह देखने के लिए वहां जाना संभव नहीं है कि क्या गलत है ...

चियर्स!

बहुत जरूरत है। धन्यवाद।

यहां आसान समीक्षा के लिए उचित लाइन एंडिंग के साथ @jcoutch पैच है: https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

यह पैच केवल विलोपन को रोकता है यदि प्रीप्रोसेसर विफल हो जाते हैं, तो यह कलाकृतियों को तब नहीं रखता है जब एक बिल्डर (उसके प्रावधानों के साथ) विफल हो जाता है।

संपादित करें: ऐसा लगता है कि इरादा है, लेकिन वास्तव में यह कुछ भी नहीं करता है, हालांकि इसे पूरा करने के लिए आसानी से तय किया जा सकता है।

हाँ, मुझे इस सूत्र का उत्तर देने का मौका नहीं मिला था। मैंने आखिरकार कोशिश की
एक गिरते हुए संयोजक के साथ मेरे बदलाव ... यह मेरी तरह काम नहीं करता है
इरादा है। कोड में गहराई से देखने पर, यह बिल्डर के हैंडल की तरह दिखता है
एक प्रावधान विफलता के बजाय कलाकृतियों का विलोपन ... कोड I के बजाय
संशोधित किया गया।

शनिवार, 3 अक्टूबर 2015 को, 9:37 AM Orivej Desh नोटिफिकेशन @github.com ने लिखा:

यहाँ उचित लाइन के साथ @jcoutch https://github.com/jcoutch पैच है
आसान समीक्षा के लिए समाप्ति: orivej @ 23bbd4d
https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/mitchellh/packer/issues/409#issuecomment -145249481।

यहां https://github.com/orivej/multistep/commit/e02bce9811c65138ea2e84c7162cd8769f35858f पहली असफलता के बाद --debug को पुनर्परिभाषित करने वाली अवधारणा का प्रमाण है। इसके लिए https://github.com/mitchellh/multistep/pull/5 को दूसरे क्लीनअप से पहले पहले क्लीनअप से पहले रोकना होगा। यह व्यवहार # 1687 में प्रस्तावित किया गया था। (यह अवधारणा का प्रमाण नहीं है लेकिन एक समाधान है यदि --debug को फिर से परिभाषित करना जैसा कि # 1687 में प्रस्तावित ठीक है।)

+1 निर्माण में विफल कलाकृतियों को -debug मोड पर संरक्षित करना।

मैं पैच के साथ थोड़ी देर के लिए पैकर चला रहा हूं, और -debug बिना इसे शुरू करने का कोई कारण नहीं था। मुझे आश्चर्य है कि क्या मुझे व्यापक परीक्षण के लिए बायनेरिज़ को प्रकाशित करना चाहिए।

+1

मैंने अभी देखा है कि मैंने जो लिंक पोस्ट किया था वह मल्टीस्टेप के लिए पैच था, पैकर के लिए नहीं। -debug साथ चलने पर त्रुटि पर पैकर पॉज़ बनाता है जो फिक्स https://github.com/orivej/packer/tree/debug-on-error पर है

@orivej यदि मुझे आपके नो-नष्ट व्यवहार पैच का परीक्षण करना है तो मुझे किस पैच के साथ शुरू करना चाहिए? https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ?

हां, एक प्रतिबद्धता है, orivej @ a713a46। यह अभी भी मास्टर पर सफाई से छूट दी जा सकती है।
आपको https://github.com/mitchellh/multistep/pull/5 से github.com/mitchellh/multistep लिए एक पैच की आवश्यकता है, या अंतिम चरण को नष्ट करने के बाद पैकर विराम देगा।

@orivej क्या आपके पास OSX के लिए एक

मैंने गर्भपात के बजाय विफल कदम को पीछे हटाने का एक विकल्प जोड़ा, हालांकि अगर यह सफल होता है तो समग्र रूप से विफल हो सकता है; और, अगर मैंने गलत नहीं किया, पैकर मज़बूती से इनपुट प्रक्रिया नहीं करता है, और उपयोगकर्ता को कई बार जवाब देना पड़ सकता है।

यह परिवर्तन पैचेड मल्टीस्टेप पर निर्भर नहीं करता है और शाखा में रहता है, प्रतिबद्ध है ।

मैंने यहाँ बायनेरिज़ अपलोड की हैं: https://orivej-packer.s3.amazonaws.com/index.html (सबट्री debug-on-error-2 )।

विफलता के बाद बॉक्स को लोड करने की संभावना होने और यह पता लगाने के लिए कि क्या गलत है मेरे लिए एक आवश्यक है।

मेरा पैच उस बॉक्स को संरक्षित नहीं करता है जिसे लोड किया जा सकता है, लेकिन इसके बजाय यह वर्तमान बॉक्स को तब तक जीवित रखता है जब तक आप मैन्युअल रूप से बिल्ड को समाप्त नहीं करते हैं, ताकि आप इसमें SSH कर सकें और डिबगिंग कर सकें (जब packer -debug साथ

प्रतिक्रिया के लिए धन्यवाद, @orivej।

मेरा पैच उस बॉक्स को संरक्षित नहीं करता है जिसे लोड किया जा सकता है, लेकिन इसके बजाय यह वर्तमान बॉक्स को तब तक जीवित रखता है जब तक कि आप मैन्युअल रूप से बिल्ड को समाप्त नहीं करते हैं, ताकि आप इसमें एसएसएच कर सकें और डिबगिंग कर सकें (जब -debug विकल्प के साथ पैकर कॉल कर रहे हैं)।

--debug साथ डिफ़ॉल्ट पैकर बिल्ड को नोट किया गया है, इससे पहले कि पर्यावरण नष्ट हो जाए आपको बताए अनुसार इसे डीबग करने का विकल्प देता है। ऐसा करने के लिए मैं "headless": false उपयोग करता हूं। आपके पैच के साथ प्रक्रिया कितनी अलग है?

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

मैंने अभी देखा कि # 2608 ने पैकर के पुराने संस्करण से नए बिलिन प्लगइन्स तक प्लगइन्स को प्राथमिकता देने का एक दुर्भाग्यपूर्ण निर्णय लिया है, इसलिए पैकर के मेरे निर्माण (या पैकर के भविष्य के रिलीज का उपयोग करने के लिए, जब तक कि लेखक इस व्यवहार पर पुनर्विचार न करें), आपको सभी को हटाने की आवश्यकता है बायनेरिज़ जिनके नाम packer- ।

अविश्वसनीय इनपुट हैंडलिंग भी # 2608 का एक गुण है, मैं देखूंगा कि क्या मैं इसे ठीक कर सकता हूं।

अविश्वसनीय इनपुट हैंडलिंग अंतर्निहित प्लगइन्स के अतिरिक्त इनिशियलाइज़ेशन के कारण होता है, विशेष रूप से setupStdin() main.go । चूँकि यह कॉल किसी भी तरह से अपने घोषित उद्देश्य को पूरा करने में असमर्थ है, इसलिए मैं इसे बिना किसी नतीजे के अक्षम कर सका, और अपने बायनेरिज़ को फिर से बनाया।

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

-Debug ध्वज उपयोगी है, लेकिन यह प्रक्रिया को मैनुअल करने के लिए बहुत कुछ करता है। बहुत बार, यह एक अनअटेंडेड बिल्ड को चलाने के लिए उपयोगी है, लेकिन क्या यह बाहर निकलता है जब यह एक त्रुटि का सामना करता है और सिस्टम को उस स्थिति में छोड़ देता है जो कारण और जांच की जांच करने की अनुमति देता है।

: +1: इस बात पर ध्यान दिए बिना कि क्या -debug पास या विफल रहता है, उदाहरण को चालू रखने का एक विकल्प होना चाहिए ताकि आप उदाहरणों पर स्क्रिप्ट / डिबग को फिर से चला सकें आदि जब तक कि यह किसी तरह एएमआई छवि को कैप्चर करने में हस्तक्षेप न करे।

+1

+1 .. मुझे आश्चर्य है कि यह लगभग 2.5 साल बाद होगा क्योंकि यह इतना उपयोगी होगा। यह मेरे जीवन को इतना आसान बना देगा कि मेरा पैकर निर्माण समस्या निवारण हो जाए।

मैं शेफ-क्लाइंट शुरू होने से पहले उदाहरण पर समाप्ति सुरक्षा का उपयोग करके AWS पर इसे दूर करने में सक्षम था। यह एक अच्छा विकल्प नहीं है, लेकिन यह काम करता है। कोई अन्य विकल्प :)

+500 - यह सुविधा अभी तक क्यों नहीं है?

शायद हम, डेवलपर्स के रूप में, शिकायत करने के बजाय अपने हाथों को गंदा करने की कोशिश कर सकते हैं?

सुविधा अनुरोध सरल नहीं हो सकता है।

• एक नया कमांड लाइन विकल्प पढ़ें ( --no-destroy-on-error )
• सही जगह पर एक विनम्र if जोड़ें। स्यूडोकोड:

unless no_destroy_on_error # add this conditional <<<<<<<<<
   perform_cleanup
end

मैं इसे एक शॉट दूँगा। और अगर यह काम करता है तो मैं इसे साझा नहीं करूंगा (ज्यादातर काल्पनिक अनुरोधों / शिकायतों से बचने के लिए)। प्रयास अच्छी बात है।

@vemv , मैंने पहले से ही इस मुद्दे को https://github.com/orivej/packer/commits/debug-on-error-2 पर दो कमिटमेंट के साथ अनिवार्य रूप से हल कर दिया है ।

@orivej यह कमाल है! मैं एक --pause-on-error जोड़ने की योजना बना रहा हूं जो मुझे लगता है कि जाने का सबसे अच्छा तरीका है (जब एक कदम सफाई से पहले कीस्ट्रोके के लिए प्रतीक्षा करने में विफल रहता है, तो उपयोगकर्ता लॉगिन और समस्या निवारण के लिए अनुमति देता है।)।

क्या आप अपने कोड के साथ एक पीआर खोल सकते हैं और हम वहां के विवरणों पर चर्चा कर सकते हैं।
CC @cbednarski

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

@orivej और @ rickard-von-Essen, उपयोगकर्ता इनपुट की आवश्यकता वाली कोई भी चीज़ मेरे लिए वास्तव में काम नहीं करती है, क्योंकि मैं केवल स्वचालित टूलिंग (यानी जेनकिंस या ट्रैविसीआई) में पैकर का उपयोग करता हूं; मुझे पता है कि मेरी स्थिति में बहुत सारे अन्य लोग भी हैं। मुझे लगता है कि मैं वास्तव में चाहता हूँ कि कुछ है (1) शायद उत्पादन की क्रियाशीलता बढ़ाता है, और (2) सिर्फ स्रोत मशीन छोड़ देता है (चाहे वह EC2, VMWare, जो भी हो) चल रहा है ताकि एक मानव निरीक्षण के बाद इसका निरीक्षण कर सके नौकरी विफल रही।

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

बस मेरा जोड़ना: +1:। मैं वास्तव में इस सुविधा का उपयोग कर सकता हूं।

@jantman मैं packer -debug क्लीनअप करने जा रहा हूं जब प्रक्रिया विफल हो जाती है और इनपुट नहीं मिल सकता (जैसे /dev/null से इनपुट के साथ)। ध्यान दें कि पैकर रन अनुक्रम विचार के आसपास बनाया गया है कि हर कदम और बाद में साफ किया जाएगा, इसलिए अचानक समाप्ति एक ऐसी स्थिति में सिस्टम को छोड़ देगा कि पैकर अपने आप से निपटने में सक्षम नहीं हो सकता है (उदाहरण के लिए यह शिकायत करेगा कि आउटपुट डायरेक्टरी पहले से मौजूद है), इसलिए आपको यह पता लगाने की अपेक्षा करनी चाहिए कि आपकी प्रक्रिया को कैसे दोहराए जाने की संभावना है, लेकिन यह आसान है।

@ rickard-von-Essen मैं अपने पैच (नए प्रदाताओं को जोड़ने) को अपडेट करूंगा और आज बाद में एक पुल अनुरोध करूंगा।

@DarwinJS से https://github.com/mitchellh/packer/issues/3445#issue -148713866 में

मैं AWS पर खिड़कियों के बक्से का निर्माण कर रहा हूं और इसमें ebs की मात्रा "delete_on_termination" सेट की गई है, इसलिए एक असफल बिल्ड के बाद मैं वॉल्यूम को संलग्न कर सकता हूं [a] वॉल्यूम संलग्न कर सकता हूं, [b] एक उदाहरण बूट करता हूं, [c] इसे लॉग देखें, [d] उदाहरण को बंद करें, [e] वॉल्यूम को अलग करें, [f] मैन्युअल रूप से वॉल्यूम हटाएं।

मैंने देखा कि c:\windows\temp<guid>.out फ़ाइलों में मेरे द्वारा चलाए जाने वाले शक्तियाँ के कंसोल आउटपुट हैं।

यह आउटपुट प्राप्त करना ही एकमात्र कारण है जिससे मुझे यह जानकारी प्राप्त करने के लिए इन सभी अतिरिक्त कदमों को उठाना पड़ा।

बहुत अच्छा होगा अगर पैकर ने PACKER_CONSOLE_LOGS_COPY=$env:temp जैसी किसी चीज़ का समर्थन किया ताकि उन लॉग्स को हमेशा वापस लाया जा सके (विशेषकर आखिरी वाला जो विफल रहा) और मैं अतिरिक्त चरणों से बच सकता था।

उन लोगों के लिए जो नवीनतम पैकर देव रिलीज को संकलित करने के मेरे लक्ष्य को साझा करते हैं और साथ ही साथ ओरिजिव को एकीकृत करते हुए पहले तय करते हैं कि पैकर निर्माण की पहली असफलता पर विराम यहां दिए गए कदम हैं जो मैंने मेरे लिए काम किया।

Complete "Setting up Go to work on Parker" steps 1-4 . ( see https://github.com/mitchellh/packer/blob/master/CONTRIBUTING.md )
git checkout master
git remote add fork https://github.com/orivej/packer
git fetch fork
git checkout -b debug-on-error fork/debug-on-error
git merge debug-on-error
make
run ./bin/packer build -debug template.json

मैं यह पुष्टि कर सकता हूं कि यह मेरे लिए काम करता है और त्रुटि होने पर ही रोक देता है।

मैं https://github.com/orivej/packer/tree/debug-on-error-2 को सफलतापूर्वक विलय करने में सक्षम नहीं था

मैं उत्सुक हूँ, मैं पैकर और गिट और इस मुद्दे पर काफी नया हूँ; क्या कोई और तरीका है जो लोग ओरिजज के फिक्स को लागू कर रहे हैं फिर मैंने कैसे वर्णन किया है? मुझे कुछ बहुत याद आ रहा है तो कृपया मुझे उस स्थिति में पकड़ें।

बस इस मुद्दे की स्थिति पर जाँच कर रहा है।

क्या यह है कि यह @orivej के परिवर्तन इस मुद्दे को संबोधित करते हैं और एक पुल अनुरोध करने की आवश्यकता है? या क्या इसे अभी भी संबोधित करने की आवश्यकता है?

+1

यह वास्तव में उपयोगी होगा, अभी मैं vm को जीवित रखने के लिए sleep 1800 साथ इनलाइन शेल का उपयोग कर रहा हूं।
कृपया ASAP लागू करें :)

Imho -debug वह कर रहा है जिसकी हम सभी को आवश्यकता है। प्रत्येक आदेश के बाद आपको अगले एक को आगे बढ़ने के लिए एन्टर प्रेस करना होगा। कोई दर्ज नहीं = vm ज़िंदा :)

@ नहीं - मैं बैठकर बिल्ड को नहीं देखता - कुछ बहुत लंबे समय तक चलने वाले सेक्शन (जैसे SQL सर्वर) स्थापित कर रहे हैं कि मैं इसे उपयोगकर्ता इनपुट के लिए होल्ड नहीं करना चाहूंगा। मैं एक टेस्ट बिल्ड को किक करना चाहूंगा और जब मैं इसमें वापस आऊंगा, तो कुछ ऐसा होगा जिसे मैं कम से कम प्रयास के साथ डिबग कर सकूं।

IMHO -debug पूरी तरह से बेकार है। मैं जटिल बिल्ड बना रहा हूं, और मुझे वास्तव में इस मुद्दे पर पहुंचने तक हजार बार दबाने का धैर्य नहीं है।
मुझे वास्तव में ऐसा नहीं लगता कि इस तरह के एक नो-ब्रेनर फ़ीचर को लागू करना इतना कठिन क्यों है।

@ henris42 जबकि मैं इस संदर्भ में -debug बेकारता पर आपसे सहमत हूं, यदि ऐसा लगता है कि ऐसा कोई नहीं-दिमाग़ी है, तो आप एक पुल अनुरोध पर क्यों नहीं देते?

@ नहीं , मैं जेन्किन्स जॉब में पैकर निर्माण को स्वचालित करता हूं (जो कि विन्यास / स्क्रिप्ट्स और अन्सिबल बुक्स से हटाता है)। इस तरह से पैकर का उपयोग करना, एक इंटरैक्टिव मोड उपयोगी नहीं है; यह एक पोस्ट विफलता analsys बहुत अधिक उपयोगी है।
मुझे लगता है कि यह DevOps की दुनिया में एक सामान्य परिदृश्य है :)

लगता है कि हर किसी को इसकी जरूरत है। इन एएमआई का निर्माण त्रुटि प्रवण है और इस सुविधा से समस्या निवारण में कम समय लगेगा

मैं @worstadmin से सहमत हूं। वैग्रैंट बॉक्स के निर्माण के मामले में, आप कई कोणों से समस्या का सामना कर सकते हैं (जैसे कि वर्चुअल मशीन को आसपास रखें, अशक्त प्रावधानक के साथ चीजों को आज़माएं, आदि), जबकि अमेज़ॅन की छवियां एक विशेष नस्ल और बहुत थकाऊ होती हैं जब यह डिबग होती है। एक मुद्दा।

Https://github.com/mitchellh/packer/issues/1687 के साथ संयुक्त यह बहुत अच्छा होगा।

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

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

झूठ नहीं बोलने पर भी, मैं किसी को 100 डॉलर का इनाम दूंगा अगर कोई गंभीरता से ASAP- को नष्ट करने की सुविधा वाला ASAP बना सकता है और इसके लिए एक पीआर पर गेंद को घुमा सकता है। मुझे (और ऐसा लगता है कि सैकड़ों अन्य) को इस सुविधा की आवश्यकता है, खासकर जब यह विचार करते हुए कि पैकर को आमतौर पर स्वचालन के साथ उपयोग किया जाता है (CI / CD / etc के माध्यम से)। तो यहाँ मेरी लंबी +1 और दलील है।

अरे एक शेल प्रोविजनर के लिए वर्कअराउंड हो सकता है, मुझे हालांकि अन्य प्रॉडक्टर्स के बारे में कोई जानकारी नहीं है। : crying_cat_face:

मेरे पास यह आज लगभग काम कर रहा था, फिर भी गो में सीखते हुए मुझे नहीं पता था कि मैं मेटाप्रोग्रामिंग नरक में फिर से इंटरफ़ेस को लागू करने के लिए कई फाइलों के माध्यम से पीछा करूँगा :(

# 3885 पर मेरा वर्तमान प्रस्ताव देखें जो पहले से ही मुझे अच्छा लग रहा है!

@tmartinx :

मैं इसे Ansible के साथ चलाने की कोशिश कर रहा हूं लेकिन, यह काम नहीं करता है और KVM अतिथि त्रुटि के बाद चला जाता है, इसलिए, यह देखने के लिए वहां जाना संभव नहीं है कि क्या गलत है ...

वर्कअराउंड के रूप में जब तक एक नया पैकर रिलीज़ नहीं होता है जिसमें # 3885 शामिल हैं:

    {
      "type": "shell",
      "inline": [
...
        "ansible-playbook ... || (echo \"*** FAILED WITH CODE $? *** Hit Ctrl-C to terminate\"; sleep 14400; exit 1)"
        ]
    }

फिर भी आपके पास अभी भी चल रहे VM में ssh करने के लिए 4 घंटे हैं और चारों ओर प्रहार करें।

यहां क्या बकवास चल रही है?

• पैकर ने एक VMware 'अज्ञात त्रुटि' का पता लगाया।
• _Packer_ ने मुझे अधिक जानकारी के लिए VMWare की लॉग फ़ाइल की जांच करने के लिए कहा। लॉग आउटपुट आउटपुट में माना जाता है।
• लेकिन _Packer स्वयं आउटपुट निर्देशिका को हटाता है, इसलिए मैं लॉग की जांच नहीं कर सकता। हा! एक अच्छा, पैकर, आप आप पर विश्वास करते हैं!
• अन्य लोगों के Shitloads एक समान स्थिति में चले गए हैं, जैसा कि वे स्पष्ट रूप से करेंगे।
• लोगों ने बहुत ही सरल, बिना दिमाग के इस समस्या को ठीक करने का अनुरोध किया है।
• उनमें से एक जोड़े ने भी खुद को ठीक करने की कोशिश करने का फैसला किया। ऐसा लगता है कि उनके पैच HashiCorp द्वारा अस्वीकार कर दिए गए हैं, या शायद वे सिर्फ असफल थे।
• किसी भी तरह से, HashiCorp ने रेडियो चुप्पी बनाए रखी है। ऐसा लगता है कि वे अभी इसे ठीक करने नहीं जा रहे हैं, कभी भी।

क्या हम यह निष्कर्ष निकाल सकते हैं कि अमेरिकी सरकार ने हाशीकॉर्प को गैग-ऑर्डर किया है और उनसे कहा है कि वे इसे ठीक न करें, या कुछ और?

मुझे वैकल्पिक स्पष्टीकरण के साथ आने में कठिन समय आ रहा है।

मुझे यह आभास हुआ है कि HashiCorp के उपकरण कुल मिलाकर DevOpsy सामान के लिए एक अच्छा विकल्प हैं, लेकिन अब मैं दूसरा विचार रख रहा हूं। गंभीरता से। क्या हम सब यहाँ कुछ स्पष्ट याद कर रहे हैं, या HashiCorp सिर्फ सुपर छायादार है?

इस टिकट को बंद करने का कारण यह है कि समस्या पहले से तय हो गई है।

फ्लैग -on-error=ask कमांड लाइन में जोड़ें, और फिर यदि कोई त्रुटि है, तो आपको संकेत दिया जाएगा कि आप बिल्ड कलाकृतियों को हटाना चाहते हैं या नहीं।

इसके अलावा, इस प्रश्न का उत्तर देने से पहले, आप VM में ssh कर सकते हैं और चारों ओर प्रहार कर सकते हैं।

@ peterlindstrom234 , यह पहले ही लागू किया जा चुका है। आप "-on-error = abort" का उपयोग कर सकते हैं और त्रुटि होने पर पैकर को कोई सफाई नहीं करनी चाहिए।

ठीक है, मेरा बुरा। हालांकि यह निश्चित रूप से अजीब समय ले लिया।

@ peterlindstrom234 को यूएस-गोवग गैग ऑर्डर के कारण लंबा समय लगा