Packer: --tidak ada perusakan pada kesalahan seperti gelandangan

Kedengarannya masuk akal. Saya pikir flag -debug memang pendekatan yang tepat di sini, tetapi mungkin flag -debug harus memungkinkan opsi seperti:

• Selesaikan setiap langkah
• Lanjutkan sampai terjadi kesalahan
• Lanjutkan sampai langkah pembersihan dimulai

Saya akan menemukan opsi untuk melanjutkan hingga kesalahan dan tidak menghancurkan vm sangat berguna

Jika seseorang dapat memberi saya beberapa petunjuk tentang di mana harus mulai mencari untuk menerapkan ini, saya mungkin dapat meluangkan waktu untuk menambahkan ini sebagai opsi

Ini akan sangat berguna juga untukku.

@timmow Anda mungkin perlu mengubah langkah pembersihan pembuatan setiap instance pembuat untuk tidak melakukan apa pun jika flag tertentu disetel (misalnya https://github.com/mitchellh/packer/blob/master/builder/amazon/common/step_run_source_instance.go # L122)

Ini akan menjadi pekerjaan yang berat untuk menyisir semua langkah dan mencari tahu di mana yang tepat untuk tidak mengambil tindakan.

Ide yang baru saja saya miliki adalah memberikan bendera yang akan menunggu masukan pengguna sebelum memproses langkah pembersihan apa pun. Dengan cara itu Anda dapat melakukan debugging, tekan enter misalnya, dan pengemas akan menangani pembersihan.

Jangan ragu untuk menghubungi saya di sini jika saya dapat menawarkan bantuan.

fyi yang dilakukan dengan cara FILO di sini https://github.com/mitchellh/multistep/blob/master/basic_runner.go#L71

Anda mungkin perlu memperpanjang runner dasar (debuggable_runner?)

Akan sangat bagus untuk menambahkan semacam fungsionalitas langkah "melewatkan" lebih rendah, yang pada dasarnya akan melewati langkah pembersihan untuk konfigurasi tipe --no-destroy-on-error . Ini juga akan mengaktifkan beberapa hal keren dalam mode -debug , seperti menekan s untuk melewati, secara interaktif.

Mirip dengan debug "jeda", menurut saya opsi seperti -pause-on-error akan bermanfaat.

Hai, Saya melihat bahwa masalah ini telah diperbaiki oleh komit https://github.com/mitchellh/packer/commit/2ed7c3f65cc2e0a14d39d8934ef1168f8192bb08 ini tetapi saya tidak melihat perubahan di KEPALA cabang master. Di mana dan mengapa itu menghilang?

Saya sangat membutuhkan ini juga.

Adakah harapan untuk memiliki fitur ini? Apa yang perlu dilakukan agar 2ed7c3f atau beberapa variasinya digabungkan?

Ya, saya juga bisa menggunakan opsi ini. Saya melihat itu dilakukan tetapi kemudian menghilang.

Apakah ada pembaruan tentang ini?

Saya akan sangat menyukai ini juga. Saya tidak dapat memberi tahu Anda berapa banyak waktu yang telah saya buang untuk mencoba men-debug masalah dan harus melalui proses pembuatan VM yang panjang untuk mendapatkan kesalahan berulang kali. Mampu mempertahankan VM akan menjadi kemenangan besar.

Apakah ada ETA saat ini (atau fungsi serupa) akan digabungkan menjadi main? Mencoba menggunakan Packer untuk membangun VM dengan Visual Studio diinstal sebagai bagian dari kotak dasar Vagrant, dan saya benar-benar membutuhkannya untuk tidak menghancurkan VM sebelum saya sempat melihat mengapa langkah-langkahnya gagal. Harus mengetahui setiap langkah melalui --debug tidak dapat diterima.

Voting lain untuk yang satu ini, karena opsi -debug menekan kegagalan yang saya coba analisis.

Menghabiskan begitu banyak waktu untuk mencoba men-debug status akhir mesin sebelum gagal. Sakelar -debug tidak memotongnya - Saya ingin menjalankan proses normal kemudian meninggalkan folder yang berfungsi dengan baik setelah gagal sehingga saya dapat mendiagnosis dengan log dan status. Benar-benar menantikan semacam pengalih status kerja.

+1 lain untuk fitur ini, itu akan sangat membantu.

+1 Mengalami masalah serupa di mana alangkah baiknya untuk men-debug status akhir, mengubah beberapa skrip penyediaan, dan kemudian menjalankan pembangunan lagi untuk melihat apakah itu memperbaiki proses, daripada menekan enter secara manual pada langkah debug yang pernah ada.

+1 lainnya untuk fitur ini. Akan menyenangkan mengetahui apa yang terjadi dengan ini? Tak seorang pun dari tim menjawab. Silakan melangkah ke piring itu tidak ada salahnya. LOL! Saya benar-benar baru mengenal Packer. Saya berada di ujung ekor dari pembuatan ISO 1,5 jam dan ini terjadi. Pengujian dan debugging harus menjadi yang terpenting untuk menghadirkan aliran aplikasi yang benar-benar manis.

Memberi +1 di sini juga, kami membuat gambar kami tanpa kepala, jadi memiliki --debug memerlukan langkah manual tidaklah baik bagi kami, tetapi dapat memeriksa gambar yang salah akan sangat bagus.

: +1: Saya juga suka memiliki fitur ini

+1 Fitur ini akan sangat bagus!

Terkait atau mungkin diduplikasi oleh # 1687

+1 Hanya untuk dapat meninggalkan VM apa adanya tanpa menghapus @error, itu akan sangat berguna. Script install kita lumayan panjang, banyak sekali langkah dengan sistem saat ini .. :(

+1 yang satu ini akan sangat berguna

+1 untuk membantu penyediaan debug saat gagal hanya dengan Packer

+1 Saya di perahu yang sama. Saya telah menghabiskan waktu berjam-jam untuk membuat ulang VM windows, hanya untuk mendapatkan kesalahan Chef dalam langkah penyediaan, dan tidak ada cara untuk men-debug VM saat dihapus. Tolong biarkan ada opsi untuk tidak menghapus semuanya selama kegagalan.

Setelah melihat masalah ini telah berlangsung selama dua tahun, saya tidak berharap ini akan diperbaiki. Saya benar-benar mencoba menyukai Packer, tetapi saya akhirnya menghabiskan lebih banyak waktu menunggu langkah pembuatan daripada benar-benar menggunakan hasilnya.

Pleeeeeaseeeeeee +1

+1

+1

+1

Ingin tahu apa argumennya untuk ini, temukan masalah ini melalui Google. Sedih ketika fitur tidak ada.

Hai devs, Saya mengunjungi kembali utas ini dan aman untuk mengatakan sementara saya telah berhasil terus menggunakan pengemas secara efektif, bug yang satu ini sangat memperlambat pengembangan sistem kami. Kami dapat melakukannya, tetapi alangkah baiknya jika seorang staf dapat memberikan beberapa panduan tentang masalah ini @mitchellh. Saya bahkan mungkin punya waktu untuk memberikan solusi jika saya dapat diarahkan ke arah yang benar, tetapi saya akan menunggu tanggapan Anda atau seseorang di tim Anda semoga. Terima kasih untuk alat yang luar biasa ini. Saya pasti ingin Anda dan tim Anda mengetahui betapa hebatnya produk ini menurut saya.

Karena saya bosan dengan semua notifikasi email +1 untuk fitur yang juga saya inginkan ;-), saya mulai menggali basis kode dan menambahkan implementasi awal. CATATAN - ini belum diuji ... dan saya bahkan tidak tahu apakah itu akan berfungsi dengan baik. Jika Anda mencoba membangunnya dari sumber, saya mengalami masalah menarik dengan referensi mandiri Packer dari github, yang akan menyebabkan kode ini tidak dibangun dengan benar. Anda harus menautkan sementara folder sumber pengemas Anda di GoPath ke folder tempat Anda mengunduh repo ini (atau tunggu saya untuk menguji dan mengirimkan permintaan tarik.)

https://github.com/jcoutch/packer

Fakta bahwa ini bukan perilaku default, jika Anda akan memaafkan bahasa Prancis saya, benar-benar gila. Ada kesalahan ketik pada skrip pemasangan Anda? Baiklah, mari kita dengan nyaman _hancurkan semua pekerjaan Anda dan jangan pernah mengembalikan waktu itu dalam hidup Anda. Lebih. Dan berakhir. Lagi._

Saya membayangkan bahwa _ secara harfiah setiap orang_ yang menggunakan alat ini untuk apa pun selain contoh yang paling sederhana mengalami masalah ini _setiap kali mereka menggunakannya_. Jelas, ada banyak permintaan untuk fitur ini, namun masih belum diterapkan, 2 tahun kemudian.

Benar-benar mengejutkan.

+1

Sobat, itu adalah komentar yang tajam. Suasana hati yang buruk kemarin, tetapi selama ini pemborosan mulai menghabiskan banyak waktu dan uang.

@jcoutch - apakah Anda memiliki bangunan yang dapat Anda bagikan?

Saya memiliki OSX yang dibangun di mesin saya, hanya saja belum memiliki kesempatan untuk menguji apakah itu
bekerja. Mengerjakan ini di waktu luang ... yang tidak banyak saya lakukan
meluangkan akhir-akhir ini. Belum lagi, ini adalah pengalaman pertama saya dengan Go (cukup
bahasa yang menarik.) Saya akan mencoba mengujinya pada akhir minggu ini,
dan jika semuanya terlihat baik, saya akan mengirimkan permintaan penarikan. Saya juga akan mencoba
posting OSX dan Windows dibangun untuk diuji orang lain setelah saya tahu itu stabil.

Pada Rabu, 23 Sep 2015, 17:14 Rich Jones [email protected] menulis:

Sobat, itu adalah komentar yang tajam. Mood buruk kemarin, tapi selama ini
pemborosan mulai menghabiskan banyak waktu dan uang.

@jcouth - apakah Anda memiliki bangunan yang dapat Anda bagikan?

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -142730452.

Pleeeease !! :-D

Saya mencoba menjalankannya dengan Ansible tetapi, itu tidak berfungsi dan tamu KVM hilang setelah kesalahan, jadi, tidak mungkin pergi ke sana untuk melihat apa yang salah ...

Bersulang!

Sangat dibutuhkan. Terima kasih.

Berikut adalah patch @jcoutch dengan akhiran baris yang tepat untuk tinjauan lebih mudah: https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

Patch ini mencegah penghapusan hanya jika preprocessor gagal, ia tidak menyimpan artefak saat builder (dengan provisionernya) gagal.

EDIT: Itu tampaknya menjadi niat, tetapi sebenarnya itu tidak melakukan apa-apa, meskipun dapat dengan mudah diperbaiki untuk memenuhinya.

Ya, saya belum sempat membalas utas ini. Saya akhirnya mencoba
perubahan saya dengan penyediaan yang jatuh ... tidak berfungsi seperti saya
dimaksudkan. Melihat lebih dalam ke kode, sepertinya pembuat menangani
penghapusan artefak karena kegagalan penyediaan ... alih-alih kode I
diubah.

Pada hari Sabtu, 3 Okt 2015, 09:37 Orivej Desh [email protected] menulis:

Berikut adalah patch @jcoutch https://github.com/jcoutch dengan baris yang tepat
akhiran agar lebih mudah ditinjau: orivej @ 23bbd4d
https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -145249481.

Di sini https://github.com/orivej/multistep/commit/e02bce9811c65138ea2e84c7162cd8769f35858f adalah bukti konsep yang mengubah --debug berhenti hanya sekali, setelah kegagalan pertama. Dibutuhkan https://github.com/mitchellh/multistep/pull/5 untuk berhenti sebelum pembersihan pertama daripada sebelum pembersihan kedua. Perilaku ini diusulkan di # 1687. (Ini bukan bukti konsep tetapi solusi jika mendefinisikan ulang --debug seperti yang diusulkan di # 1687 tidak masalah.)

+1 untuk melestarikan artefak pada build dalam mode -debug yang gagal.

Saya telah menjalankan pengemas untuk beberapa waktu dengan tambalan, dan tidak pernah punya alasan untuk memulainya tanpa -debug . Saya ingin tahu apakah saya harus menerbitkan binari untuk pengujian yang lebih luas.

+1

Saya baru saja memperhatikan bahwa tautan yang saya posting adalah tambalan untuk multistep, bukan untuk pengemas. Perbaikan yang membuat pengemas berhenti pada kesalahan saat menjalankan dengan -debug ada di https://github.com/orivej/packer/tree/debug-on-error

@orivej patch mana yang harus saya mulai jika saya ingin menguji patch perilaku tanpa https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ?

Ya, ada satu komit, orivej @ a713a46. Itu masih bisa dengan rapi didasarkan pada master.
Anda juga memerlukan tambalan untuk github.com/mitchellh/multistep dari https://github.com/mitchellh/multistep/pull/5 , atau pengemas akan berhenti sebentar setelah menghancurkan langkah terakhir.

@orivej apakah Anda memiliki biner yang ditambal untuk OSX? Memulai ulang seluruh proses build karena kesalahan kecil saat membangun box Gentoo Linux sangatlah menyakitkan (memakan waktu). Memiliki kemungkinan untuk memuat kotak setelah kegagalan dan mencari tahu apa yang salah adalah suatu keharusan bagi saya.

Saya menambahkan opsi untuk mencoba lagi langkah yang gagal alih-alih membatalkan, meskipun ini berhasil secara keseluruhan, build mungkin gagal; dan, jika saya tidak keliru, pengemas tidak dapat diandalkan memproses masukan, dan pengguna mungkin harus merespons beberapa kali.

Perubahan ini tidak bergantung pada multistep yang ditambal dan tinggal di branch , commit .

Saya mengunggah binari di sini: https://orivej-packer.s3.amazonaws.com/index.html (subtree debug-on-error-2 ).

Memiliki kemungkinan untuk memuat kotak setelah kegagalan dan mencari tahu apa yang salah adalah suatu keharusan bagi saya.

Patch saya tidak menyimpan kotak yang dapat dimuat, tetapi membiarkan kotak saat ini hidup sampai Anda secara manual menghentikan build, sehingga Anda dapat SSH ke dalamnya dan melakukan debugging (saat memanggil packer dengan -debug opsi).

Terima kasih atas umpan baliknya, @orivej.

Patch saya tidak menyimpan kotak yang dapat dimuat, tetapi membiarkan kotak saat ini hidup sampai Anda secara manual menghentikan build, sehingga Anda dapat SSH ke dalamnya dan melakukan debugging (saat memanggil pengemas dengan opsi -debug).

Memperhatikan pembangunan pengemas default, dengan --debug , berhenti sebelum lingkungan dihancurkan memberi Anda opsi untuk men-debug seperti yang Anda jelaskan. Untuk melakukan itu saya menggunakan "headless": false . Seberapa berbeda prosesnya dengan tambalan Anda?

• Itu membuat pengemas berhenti hanya setelah satu langkah gagal, bukannya berhenti setelah setiap langkah.
• Ini berhenti sebelum pengemas membersihkan setelah langkah gagal. (Meskipun saya tidak ingat mengapa saya membutuhkan ini, karena langkah penyediaan yang paling bermasalah tidak melakukan pembersihan apa pun.)
• Edisi kedua dari tambalan memungkinkan untuk mencoba kembali langkah yang gagal. (Saat penyediaan gagal, ini menjalankan ulang semua penyedia.)

Saya baru saja memperhatikan bahwa # 2608 membuat keputusan yang tidak menguntungkan untuk memprioritaskan plugin dari versi lama pengemas ke plugin bawaan yang lebih baru, jadi untuk menggunakan versi pengemas saya (atau rilis pengemas di masa mendatang, kecuali jika penulis mempertimbangkan kembali perilaku ini), Anda perlu menghapus semua biner yang namanya dimulai dengan packer- .

Penanganan masukan yang tidak dapat diandalkan juga merupakan artefak # 2608, saya akan melihat apakah saya dapat memperbaikinya.

Penanganan input yang tidak dapat diandalkan disebabkan oleh inisialisasi tambahan dari plugin bawaan, khususnya oleh setupStdin() dalam main.go . Karena panggilan ini tampaknya tidak dapat melayani tujuan yang dinyatakan, saya dapat menonaktifkannya tanpa dampak, dan membangun kembali binari saya.

Hanya bisa keluar dari pengemas tanpa menghentikan atau menghancurkan VM saat terjadi kesalahan, akan sangat berguna. Ini terutama penting dalam komponen penyediaan yang biasanya berisi logika paling khusus. Mampu melakukan SSH ke dalam kotak dan menjalankan kembali skrip asli atau mencoba skrip atau resep yang dimodifikasi untuk pengujian dapat memberikan wawasan yang cepat dan berharga tentang apa yang sebenarnya menyebabkan kesalahan dan apa perbaikannya. Melakukan keseluruhan pembuatan pengemas terlalu memakan waktu untuk membutuhkannya bahkan untuk pemecahan masalah yang paling sederhana.

Flag -debug berguna, tetapi membuat prosesnya lebih manual. Seringkali, sangat berguna untuk menjalankan build tanpa pengawasan, tetapi membuatnya keluar saat menemui error dan membiarkan sistem dalam keadaan yang memungkinkan penyelidikan penyebab dan perbaikan.

: +1: terlepas dari apakah -debug lolos atau gagal, harus ada opsi untuk tetap menjalankan instance sehingga Anda dapat memutar ulang skrip / debug pada instance, dll. Kecuali jika hal ini mengganggu pengambilan gambar AMI.

+1

+1 .. Saya terkejut ini akan terjadi sekitar 2,5 tahun kemudian karena akan sangat berguna. Ini akan membuat hidup saya jauh lebih mudah untuk memecahkan masalah yang saya buat dengan Packer.

Saya dapat mengatasi masalah ini di AWS dengan menggunakan perlindungan penghentian pada instans sebelum klien-koki dimulai. ini bukan pilihan yang layak tapi hei itu berhasil. Pilihan lain :)

+500 - mengapa fitur ini belum masuk?

Mungkin kita, sebagai pengembang, bisa mencoba mengotori tangan kita daripada mengeluh?

Permintaan fitur sangat sederhana.

• Baca opsi baris perintah baru ( --no-destroy-on-error )
• Tambahkan if di tempat yang tepat. Pseudocode:

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

Saya akan mencobanya. Dan jika berhasil, saya tidak akan membagikannya (kebanyakan untuk menghindari permintaan / keluhan hipotetis). Usaha adalah hal yang baik.

@vemv , pada dasarnya saya sudah memecahkan masalah ini dengan dua komitmen di https://github.com/orivej/packer/commits/debug-on-error-2.

@orivej Itu luar biasa! Saya telah berencana untuk menambahkan --pause-on-error yang menurut saya merupakan cara terbaik untuk melakukannya (ketika langkah gagal, tunggu penekanan tombol sebelum membersihkan, memungkinkan pengguna untuk masuk dan memecahkan masalah.).

Bisakah Anda membuka PR dengan kode Anda dan kami dapat mendiskusikan detailnya di sana.
CC @bedagama

@vemv Saya telah mengikuti masalah ini selama beberapa tahun. Saya hanya dapat berbicara untuk diri saya sendiri, tetapi saya tidak benar-benar tahu tentang Go sama sekali, setidaknya lebih dari sekadar mengotak-atik dan mencari tahu kode apa yang mungkin dilakukan. Saya tidak akan nyaman menulis kode untuk sesuatu yang banyak digunakan seperti Packer, apalagi mengujinya dengan benar.

@orivej dan @ rickard-von-essen, apa pun yang memerlukan masukan pengguna tidak benar-benar berfungsi untuk saya, karena saya hanya menggunakan Packer dalam perkakas otomatis (yaitu Jenkins atau TravisCI); Saya tahu ada banyak orang lain di posisi saya juga. Saya pikir apa yang benar-benar saya inginkan adalah sesuatu yang (1) mungkin meningkatkan verbositas output, dan (2) membiarkan mesin sumber (apakah itu EC2, VMWare, apa pun) berjalan sehingga manusia dapat memeriksanya setelah pekerjaan gagal.

Saat ini debug akan berhenti di antara langkah-langkah, mengharuskan Anda untuk menekan enter untuk melanjutkan, jadi selama Anda tahu langkah mana yang akan gagal, Anda hanya dapat 'menahan' VM di sana untuk tujuan debug tetapi jelas itu tidak sebaik itu. Anda benar-benar ingin templat melalui setiap langkah sehingga Anda dapat memeriksa status gagal sepenuhnya.

Hanya menambahkan saya: +1 :. Saya benar-benar dapat menggunakan fitur ini.

@jantman Saya akan membuat packer -debug melewatkan pembersihan ketika proses gagal dan tidak bisa mendapatkan input (misalnya dengan input dari /dev/null ). Perhatikan bahwa urutan proses pemaket dibangun di sekitar gagasan bahwa setiap langkah dapat dan akan dibersihkan setelahnya, jadi penghentian mendadak akan membuat sistem dalam keadaan yang mungkin tidak dapat ditangani oleh pemaket sendiri (misalnya, ia akan mengeluh bahwa direktori keluaran sudah ada), jadi Anda harus memikirkan cara membuat proses Anda berulang, tetapi ini kemungkinan besar mudah.

@ rick-von-essen Saya akan memperbarui tambalan saya (menambah penyedia baru) dan membuat permintaan tarik nanti hari ini.

Dari @DarwinJS di https://github.com/mitchellh/packer/issues/3445#issue -148713866

Saya membuat kotak jendela di AWS dan volume ebs "delete_on_termination" disetel ke false sehingga setelah build yang gagal saya dapat [a] melampirkan volume, [b] mem-boot sebuah instance, [c] melihat lognya, [d] matikan instance, [e] lepaskan volume, [f] hapus volume secara manual.

Saya perhatikan file c:\windows\temp<guid>.out berisi output konsol dari provisi PowerShell yang saya jalankan.

Mendapatkan hasil ini adalah satu-satunya alasan saya harus mengambil semua langkah tambahan ini untuk mendapatkan informasi ini.

Akan lebih bagus jika Packer mendukung sesuatu seperti PACKER_CONSOLE_LOGS_COPY=$env:temp sehingga log tersebut selalu dapat dibawa kembali (terutama yang terakhir gagal) dan saya dapat menghindari langkah-langkah tambahan.

Bagi mereka yang berbagi tujuan saya untuk mengkompilasi rilis dev pengemas terbaru sementara juga mengintegrasikan perbaikan orivej sebelumnya yang berhenti pada kegagalan pertama pembuatan pengemas, berikut adalah langkah-langkah yang saya ambil yang berhasil untuk saya.

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

Saya dapat mengonfirmasi bahwa ini berhasil untuk saya dan penyediaan hanya dijeda jika ada kesalahan.

Saya tidak berhasil menggabungkan https://github.com/orivej/packer/tree/debug-on-error-2.

Saya penasaran, saya cukup baru mengenal packer dan git dan masalah ini; apakah ada cara lain yang dilakukan orang untuk mengimplementasikan perbaikan orivej, lalu seperti yang saya jelaskan? Saya mungkin melewatkan sesuatu yang sangat jelas jadi tolong beri tahu saya jika itu masalahnya.

Hanya memeriksa status masalah ini.

Apakah itu perubahan @orivej yang mengatasi masalah ini dan permintaan tarik perlu dibuat? Atau apakah ini masih perlu dibenahi?

+1

itu akan sangat berguna, sekarang saya menggunakan shell inline dengan sleep 1800 untuk menjaga vm tetap hidup.
Harap terapkan ASAP :)

Imho -debug melakukan apa yang kita semua butuhkan. Setelah setiap perintah, Anda perlu menekan enter untuk melanjutkan perintah berikutnya. Tidak masuk = vm hidup :)

@ Noose - Saya tidak duduk dan menonton build - ada beberapa bagian yang berjalan sangat lama (seperti menginstal SQL server) yang saya tidak ingin menahannya untuk input pengguna. Saya ingin memulai uji coba dan ketika saya kembali ke sana, memiliki sesuatu yang dapat saya debug dengan sedikit usaha.

IMHO the -debug sama sekali tidak berguna. Saya menjalankan build yang rumit, dan saya benar-benar tidak memiliki kesabaran untuk menekan enter ribuan kali sampai saya mendapatkan masalah tersebut.
Saya benar-benar tidak mengerti mengapa fitur no-brainer seperti ini sangat sulit untuk diterapkan.

@ henris42 sementara saya setuju dengan Anda tentang ketidakbergunaan -debug dalam konteks ini, jika tampaknya seperti no-brainer, mengapa Anda tidak mencoba permintaan tarik?

@noose , saya mengotomatiskan pembuat paket dalam pekerjaan Jenkins (yang menarik dari Git config / scripts dan buku pedoman yang mungkin). Menggunakan pengemas dengan cara ini, mode interaktif tidak berguna; jauh lebih berguna analsys kegagalan pasca.
Saya pikir ini adalah skenario umum di dunia DevOps :)

Sepertinya semua orang membutuhkan ini. Membangun AMI ini rawan kesalahan dan fitur ini akan mengurangi waktu yang dibutuhkan untuk memecahkan masalah

Saya setuju dengan @worstadmin. Dalam kasus membuat kotak Vagrant, Anda dapat mengatasi masalah dari berbagai sudut (misalnya, menjaga mesin virtual tetap ada, mencoba hal-hal dengan penyedia null, dll.), Sedangkan gambar Amazon adalah jenis khusus dan sangat melelahkan untuk di-debug ketika ada sebuah isu.

Dikombinasikan dengan https://github.com/mitchellh/packer/issues/1687 ini akan bagus.

Selain itu, sering kali membantu untuk mengabaikan kesalahan dari penyedia dan membiarkannya berlanjut, terutama selama tahap awal pengembangan gambar, dll.

Hampir 3 tahun kemudian ... dan masih hampir tidak ada. Saya telah menghabiskan beberapa hari terakhir menghancurkan kepala saya pada keyboard mencoba melakukan pembangunan jendela kompleks yang secara sewenang-wenang dan secara acak gagal mengeksekusi skrip PowerShell tanpa output dan karena pembersihan otomatis saya tidak dapat melompat ke instance. Ketika saya menjalankan dengan -debug diaktifkan, tambahan "jeda" yang diperkenalkan dengan meminta entri manual tampaknya menyebabkan masalah ini tidak terjadi. Yang mana, menurut Anda itu masuk akal, saya hanya menambahkan satu ton sleep ke dalam skrip PowerShell saya untuk mensimulasikan ini, dan itu tidak membantu.

Bahkan tidak berbohong, saya akan memberi orang lain Paypal hadiah $ 100 jika seseorang benar-benar dapat membuat fitur --tidak menghancurkan-pada-kesalahan secepatnya dan mendapatkan bola bergulir dengan PR untuk ini. Saya (dan sepertinya ratusan lainnya) membutuhkan fitur ini, terutama mengingat bahwa pengemas biasanya digunakan dengan otomatisasi (melalui CI / CD / dll). Jadi inilah +1 panjang dan permohonan saya.

Hai, mungkin ada solusi untuk penyedia shell, saya tidak tahu tentang penyedia lain. : scream_cat_face:

Saya sudah hampir bekerja hari ini, namun belajar ke Go Saya tidak tahu bahwa saya akan mendarat di neraka metaprogramming lagi mengejar antarmuka melalui beberapa file untuk menemukan implementasinya :(

Lihat proposal saya saat ini di # 3885 yang sudah terlihat bagus untuk saya!

@tmartinx :

Saya mencoba menjalankannya dengan Ansible tetapi, itu tidak berfungsi dan tamu KVM hilang setelah kesalahan, jadi, tidak mungkin pergi ke sana untuk melihat apa yang salah ...

Sebagai solusinya hingga ada rilis pengemas baru yang berisi # 3885:

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

Anda kemudian memiliki 4 jam untuk ssh ke VM yang masih berjalan dan melihat-lihat.

Apa yang sebenarnya terjadi disini?

• Packer mendeteksi 'Kesalahan Tidak Dikenal' VMware.
• _Packer_ menyuruh saya untuk memeriksa file log VMWare untuk informasi lebih lanjut. Log seharusnya ada di direktori keluaran.
• Tapi _Packer sendiri_ menghapus direktori keluaran, jadi saya tidak bisa memeriksa log. Ha ha! Bagus, Packer, kau bajingan!
• Masalah orang lain telah mengalami situasi yang sama, seperti yang jelas mereka alami.
• Orang-orang terus meminta perbaikan yang tampaknya sangat sederhana dan tidak perlu dipikirkan untuk masalah ini _selama bertahun-tahun_ sekarang.
• Beberapa dari mereka bahkan memutuskan untuk mencoba dan memperbaikinya sendiri. Sepertinya tambalan mereka telah ditolak oleh HashiCorp, atau mungkin mereka tidak berhasil.
• Bagaimanapun, HashiCorp telah mempertahankan keheningan radio. Sepertinya mereka tidak akan pernah memperbaiki ini, selamanya.

Apakah kita dapat menyimpulkan bahwa pemerintah AS telah melakukan lelucon terhadap HashiCorp dan mengatakan kepada mereka untuk tidak memperbaikinya, atau semacamnya?

Saya kesulitan menemukan penjelasan alternatif.

Saya mendapat kesan bahwa alat HashiCorp adalah pilihan yang baik untuk hal-hal DevOpsy secara keseluruhan, tapi sekarang saya berubah pikiran. Sungguh. Apakah kita semua melewatkan sesuatu yang jelas di sini, atau apakah HashiCorp hanya bersikap sangat teduh?

Alasan penutupan tiket ini karena masalahnya sudah diperbaiki.

Tambahkan bendera -on-error=ask ke baris perintah, dan kemudian jika ada kesalahan Anda akan ditanya apakah Anda ingin menghapus artefak build atau tidak.

Selanjutnya, sebelum menjawab pertanyaan ini, Anda dapat ssh ke VM dan melihat-lihat.

@ peterlindstrom234 , ini telah diterapkan. Anda dapat menggunakan "-on-error = abort" dan pengemas tidak boleh melakukan pembersihan apa pun saat terjadi kesalahan.

Baiklah, salahku. Itu pasti butuh waktu lama yang aneh.

@ peterlindstrom234 butuh waktu lama karena perintah bungkam pemerintah AS