Packer: --no-destroy-on-error comme Vagrant

Cela semble raisonnable. Je pense que le drapeau -debug est en effet la bonne approche ici, mais peut-être que le drapeau -debug devrait autoriser des options telles que:

• Passez à chaque étape
• Continuer jusqu'à une erreur
• Continuez jusqu'au début des étapes de nettoyage

Je trouverais l'option de continuer jusqu'à une erreur et de ne pas détruire le vm extrêmement utile

Si quelqu'un peut me donner des indications sur où commencer à chercher à mettre en œuvre cela, je pourrai peut-être consacrer du temps à l'ajouter en option

Cela me serait également très utile.

@timmow, vous devrez peut-être modifier l'étape de nettoyage de création d'instance de chaque générateur pour ne rien faire si un certain indicateur est défini (par exemple https://github.com/mitchellh/packer/blob/master/builder/amazon/common/step_run_source_instance.go # L122)

Ce serait une certaine quantité de travail pour parcourir toutes les étapes et déterminer où il serait approprié de ne prendre aucune mesure.

Une idée que je viens d'avoir serait de donner un indicateur qui attendrait l'entrée de l'utilisateur avant de traiter toute étape de nettoyage. De cette façon, vous pourriez effectuer votre débogage, appuyez sur Entrée par exemple, et le packer s'occuperait du nettoyage.

N'hésitez pas à me cingler ici si je peux offrir de l'aide.

fyi qui est fait de manière FILO ici https://github.com/mitchellh/multistep/blob/master/basic_runner.go#L71

vous devrez peut-être étendre le runner de base (debuggable_runner?)

Ce serait génial d'ajouter une sorte de fonctionnalité "saut" d'étape plus bas, qui passerait fondamentalement les étapes de nettoyage pour cette configuration de type --no-destroy-on-error . Cela permettrait également des trucs sympas dans le mode -debug , comme appuyer sur s pour sauter, de manière interactive.

Semblable au débogage "pause", je pense qu'une option comme -pause-on-error serait bénéfique.

Salut, je vois que ce problème est résolu par ce commit https://github.com/mitchellh/packer/commit/2ed7c3f65cc2e0a14d39d8934ef1168f8192bb08 mais je ne vois pas le changement dans HEAD de la branche principale. Où et pourquoi a-t-il disparu?

J'ai vraiment besoin de ça aussi.

Y a-t-il un espoir d'avoir cette fonctionnalité? Que faut-il faire pour que 2ed7c3f ou une variante de celui-ci fusionne?

Ouais, je pourrais aussi utiliser cette option. Je vois qu'il a été commis mais a ensuite disparu.

Y a-t-il une mise à jour à ce sujet?

J'adorerais vraiment ça aussi. Je ne peux pas vous dire combien de temps j'ai perdu à essayer de déboguer les problèmes et que je dois passer par un long processus de création de VM pour revenir à l'erreur encore et encore. Être capable de conserver la VM serait une énorme victoire.

Y a-t-il un ETA lorsque cette (ou une fonctionnalité similaire) sera fusionnée avec main? Essayer d'utiliser Packer pour créer une machine virtuelle avec Visual Studio installé dans le cadre de la boîte de base Vagrant, et j'en ai vraiment besoin pour ne pas détruire la machine virtuelle avant d'avoir eu la chance de voir pourquoi les étapes échouent. Avoir à reconnaître chaque étape via --debug n'est pas acceptable.

Un autre vote pour celui-ci, car l'option -debug supprime l'échec que j'essaie d'analyser.

Passer tellement de temps à essayer de déboguer l'état final de la machine avant qu'elle échoue. Le commutateur -debug ne le coupe pas - je veux qu'il s'exécute dans le processus normal, puis laisse le dossier de travail intact après l'échec afin que je puisse diagnostiquer avec les journaux et l'état. J'attends vraiment avec impatience une sorte de commutateur d'état de fonctionnement préservé.

Un autre +1 pour cette fonctionnalité, ce serait extrêmement utile.

+1 Se heurter à des problèmes similaires où il serait bien de déboguer l'état final, d'ajuster certains scripts d'approvisionnement, puis de réexécuter la construction pour voir si cela corrigeait le processus, plutôt que d'appuyer manuellement sur Entrée à chaque étape de débogage.

Un autre + 1 pour cette fonctionnalité. Ce serait bien de savoir ce qui est arrivé à cela? Personne de l'équipe n'a répondu. Allez-y, montez à l'assiette, ça ne fait pas mal. LOL! Je suis totalement nouveau chez Packer. J'étais à la fin d'une construction ISO de 1,5 heure et c'est arrivé. Les tests et le débogage devraient être primordiaux pour apporter un flux complet d'application totalement doux.

+1 ici aussi, nous créons nos images sans tête, donc avoir --debug nécessite une étape manuelle n'est pas bon pour nous, mais pouvoir inspecter l'image défectueuse serait génial.

: +1: J'aime aussi avoir cette fonctionnalité

+1 Cette fonctionnalité serait géniale!

Lié à ou peut-être dupliqué par # 1687

+1 Juste pour pouvoir laisser la VM telle quelle sans supprimer @error, ce serait très utile. Nos scripts d'installation sont assez longs, beaucoup de pas avec le système actuel .. :(

+1 celui-ci sera très utile

+1 pour aider au débogage de l'approvisionnement en cas d'échec uniquement avec Packer

+1 Je suis dans le même bateau. J'ai passé des heures incalculables à recréer des machines virtuelles Windows, seulement pour avoir une erreur Chef dans l'étape de provisionnement, et aucun moyen de déboguer la machine virtuelle lorsqu'elle est supprimée. Veuillez simplement laisser une option pour ne pas tout supprimer en cas d'échec.

Après avoir vu que ce problème existe depuis deux ans, je n'ai aucun espoir que cela soit corrigé. J'essaie vraiment d'aimer Packer, mais je finis par passer plus de temps à attendre l'étape de construction qu'à utiliser réellement les résultats.

Pleeeeeaseeeeeee +1

+1

+1

+1

Je me suis demandé quel était l'argument pour cela, j'ai trouvé ce problème via Google. Je suis triste quand la fonctionnalité n'existait pas.

Salut les développeurs, j'ai revisité ce fil de discussion et je suis sûr de dire que même si j'ai réussi à continuer à utiliser efficacement packer, ce bogue ralentit sérieusement le développement de nos systèmes. Nous pouvons nous débrouiller, mais ce serait vraiment bien si un membre du personnel pouvait fournir des conseils sur cette question @mitchellh. J'aurai peut-être même le temps d'apporter une solution si je peux être orienté dans la bonne direction, mais j'attendrai votre réponse ou un membre de votre équipe, espérons-le. Merci pour cet outil incroyable. Je veux vraiment que vous et votre équipe sachiez à quel point je pense que ce produit est génial.

Depuis que je suis fatigué de toutes les notifications par e-mail +1 pour une fonctionnalité que je voulais aussi ;-), j'ai commencé à fouiller dans la base de code et j'ai ajouté une implémentation initiale. REMARQUE - ce n'est pas encore testé ... et je ne sais même pas si cela fonctionnera correctement. Si vous essayez de le construire à partir des sources, j'ai rencontré un problème intéressant avec l'auto-référencement de Packer à partir de github, ce qui empêchera ce code de se construire correctement. Vous devrez temporairement lier votre dossier source du packer dans GoPath au dossier dans lequel vous téléchargez ce dépôt (ou attendez que je teste et soumette une pull request.)

https://github.com/jcoutch/packer

Le fait que ce ne soit pas le comportement par défaut, si vous pardonnez mon français, est complètement fou. Vous avez fait une faute de frappe dans votre script d'installation? Eh bien, nous allons simplement _détruire tout votre travail et ne jamais vous rendre cette heure de votre vie. Plus de. Et plus. Encore._

J'imagine que _littéralement chaque personne_ qui utilise cet outil pour quoi que ce soit au-delà des exemples les plus simples se heurte à ce problème _ chaque fois qu'elle l'utilise_. Clairement, il y a une demande massive pour cette fonctionnalité, et pourtant elle n'est toujours pas implémentée, 2 ans plus tard.

Absolument stupéfiant.

+1

Mec, c'était un commentaire sarcastique. Mauvaise humeur hier, mais tout ce temps perdu commence à coûter beaucoup de temps et d'argent.

@jcoutch - avez-vous une version que vous pouvez partager?

J'ai une version OSX sur ma machine, je n'ai tout simplement pas eu l'occasion de tester si elle
fonctionne encore. Travailler là-dessus pendant mon temps libre ... ce que je n'ai pas eu beaucoup à faire
épargner ces derniers temps. Sans oublier, c'est ma première expérience avec Go (assez
une langue intéressante.) Je vais essayer de la tester d'ici la fin de cette semaine,
et si tout semble bon, je soumettrai une pull request. J'essaierai aussi de
post des builds OSX et Windows pour que d'autres testent une fois que je sais que c'est stable.

Le mercredi 23 septembre 2015, 17 h 14, Rich Jones [email protected] a écrit:

Mec, c'était un commentaire sarcastique. Mauvaise humeur hier, mais tout ce temps
le gaspillage commence à coûter beaucoup de temps et d'argent.

@jcouth - avez-vous une version que vous pouvez partager?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -142730452.

Pleeeease !! :-RÉ

J'essaie de l'exécuter avec Ansible mais cela ne fonctionne pas et l'invité KVM est parti après l'erreur, donc, il n'est pas possible d'y aller pour voir ce qui ne va pas ...

À votre santé!

Bien nécessaire. Merci.

Voici le patch @jcoutch avec les fins de ligne appropriées pour un examen plus facile: https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

Ce correctif empêche la suppression uniquement en cas d'échec des préprocesseurs, il ne conserve pas les artefacts lorsqu'un générateur (avec ses approvisionneurs) échoue.

EDIT: Cela semble être l'intention, mais en fait cela ne fait rien, même si cela pourrait être facilement corrigé pour y répondre.

Ouais, je n'avais pas eu l'occasion de répondre à ce fil. J'ai finalement essayé
mes changements avec un approvisionneur en baisse ... cela ne fonctionne pas comme je
prévu. En regardant plus profondément dans le code, il ressemble aux poignées du constructeur
la suppression d'artefacts en cas d'échec de provisionnement ... au lieu du code I
modifié.

Le samedi 3 octobre 2015, 9 h 37, Orivej Desh [email protected] a écrit:

Voici le patch @jcoutch https://github.com/jcoutch avec la ligne appropriée
fins pour un examen plus facile: orivej @ 23bbd4d
https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -145249481.

Ici https://github.com/orivej/multistep/commit/e02bce9811c65138ea2e84c7162cd8769f35858f est une preuve de concept qui redéfinit --debug pour s'arrêter une seule fois, après le premier échec. Il faut que https://github.com/mitchellh/multistep/pull/5 s'arrête avant le premier nettoyage plutôt qu'avant le deuxième nettoyage. Ce comportement a été proposé dans # 1687. (Ce n'est pas une preuve de concept mais une solution si la redéfinition de --debug comme proposé dans # 1687 est OK.)

+1 à la préservation des artefacts sur une compilation échouée en mode -debug.

J'utilise Packer depuis un certain temps avec le patch, et je n'ai jamais eu de raison de le démarrer sans -debug . Je me demande si je devrais publier des binaires pour des tests plus larges.

+1

Je viens de remarquer que le lien que j'ai posté était un patch pour plusieurs étapes, pas pour packer. Le correctif qui met le packer en pause en cas d'erreur lors de l'exécution avec -debug est sur https://github.com/orivej/packer/tree/debug-on-error

@orivej avec quel patch dois-je commencer si je veux tester votre patch de comportement sans destruction? https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ?

Oui, il existe un commit, orivej @ a713a46. Il peut toujours être proprement rebasé sur master.
Vous avez également besoin d'un correctif pour github.com/mitchellh/multistep de https://github.com/mitchellh/multistep/pull/5 , sinon le packer se mettra en pause après avoir détruit la dernière étape.

@orivej avez-vous un binaire patché pour OSX? Redémarrer tout le processus de construction en raison d'une petite erreur lors de la construction d'une machine Gentoo Linux est incroyablement pénible (prend du temps). Avoir la possibilité de charger la boîte après la panne et de découvrir ce qui ne va pas est un must pour moi.

J'ai ajouté une option pour réessayer l'étape qui a échoué au lieu d'abandonner, même si même si cela réussit, la construction globale peut échouer; et, si je ne me suis pas trompé, le packer ne traite pas les entrées de manière fiable, et l'utilisateur peut devoir répondre plusieurs fois.

Ce changement ne dépend pas de plusieurs étapes corrigées et vit dans la branche , commit .

J'ai téléchargé des binaires ici: https://orivej-packer.s3.amazonaws.com/index.html (sous-arbre debug-on-error-2 ).

Avoir la possibilité de charger la boîte après la panne et de découvrir ce qui ne va pas est un must pour moi.

Mon patch ne préserve pas la boîte qui peut être chargée, mais laisse à la place la boîte actuelle active jusqu'à ce que vous terminiez manuellement la construction, afin que vous puissiez y SSH et effectuer le débogage (lors de l'appel de packer avec -debug option

Merci pour vos commentaires, @orivej.

Mon correctif ne conserve pas la boîte qui peut être chargée, mais laisse à la place la boîte actuelle active jusqu'à ce que vous terminiez manuellement la construction, afin que vous puissiez y SSH et effectuer le débogage (lors de l'appel de packer avec l'option -debug).

Vous avez remarqué que la construction du packer par défaut, avec --debug , fait une pause avant que l'environnement ne soit détruit, vous donnant la possibilité de le déboguer comme vous l'avez décrit. Pour ce faire, j'utilise "headless": false . Dans quelle mesure le processus avec votre patch est-il différent?

• Il ne met le packer en pause qu'après l'échec d'une étape, au lieu de s'arrêter après chaque étape.
• Il s'arrête avant que le packer nettoie après l'échec de l'étape. (Bien que je ne me souvienne pas pourquoi j'avais besoin de cela, puisque l'étape de provisionnement la plus problématique ne fait aucun nettoyage.)
• La deuxième édition du correctif permet de réessayer l'étape qui a échoué. (Lorsque l'approvisionnement échoue, cela réexécute tous les approvisionneurs.)

Je viens de remarquer que # 2608 a pris une décision malheureuse de donner la priorité aux plugins de l'ancienne version de packer aux plugins intégrés plus récents, donc pour utiliser ma version de packer (ou les futures versions de packer, à moins que les auteurs ne reconsidèrent ce comportement), vous devez tout supprimer binaires dont les noms commencent par packer- .

La gestion des entrées peu fiable est également un artefact du # 2608, je vais voir si je peux le réparer.

La gestion non fiable des entrées est causée par une initialisation supplémentaire des plugins intégrés, en particulier par setupStdin() dans main.go . Étant donné que cet appel semble de toute façon incapable de servir son objectif déclaré, j'ai pu le désactiver sans répercussions et reconstruire mes binaires.

Il serait très utile de pouvoir simplement quitter le packer sans arrêter ou détruire la VM en cas d'erreur. Ceci est particulièrement important dans les composants d'approvisionnement qui contiennent généralement la logique la plus personnalisée. Être capable de SSH dans une boîte et de réexécuter le script d'origine ou d'essayer un script modifié ou une recette de test peut fournir des informations rapides et précieuses sur ce qui a réellement causé l'erreur et quel est le correctif. Faire un packer complet prend beaucoup trop de temps pour l'exiger, même pour le dépannage le plus simple.

L'indicateur -debug est utile, mais il rend le processus beaucoup plus manuel. Très souvent, il est utile d'exécuter une compilation sans assistance, mais de la faire quitter lorsqu'elle rencontre une erreur et de laisser le système dans un état permettant d'en rechercher la cause et de la corriger.

: +1: indépendamment du fait que -debug réussisse ou échoue, il devrait y avoir une option pour maintenir l'instance en cours d'exécution afin que vous puissiez relire les scripts / déboguer sur l'instance, etc. Sauf si cela interfère d'une manière ou d'une autre avec la capture de l'image AMI.

+1

+1 .. Je suis surpris que ce soit environ 2,5 ans plus tard car ce serait si utile. Cela me faciliterait la vie en résolvant les problèmes de ma version Packer.

J'ai pu surmonter ce problème sur AWS en utilisant la protection de résiliation sur l'instance avant le démarrage du client chef. ce n'est pas une option décente mais bon ça marche. Toutes les autres options :)

+500 - pourquoi cette fonctionnalité n'est-elle pas encore disponible?

Peut-être que nous, en tant que développeurs, pourrions essayer de nous salir les mains au lieu de nous plaindre?

La demande de fonctionnalité ne pourrait pas être plus simple.

• Lire une nouvelle option de ligne de commande ( --no-destroy-on-error )
• Ajoutez un humble if au bon endroit. Pseudocode:

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

Je vais essayer. Et si cela fonctionne, je ne le partagerai pas (principalement pour éviter les demandes / plaintes hypothétiques). L'effort est une bonne chose.

@vemv , j'ai déjà essentiellement résolu ce problème avec deux commits sur https://github.com/orivej/packer/commits/debug-on-error-2.

@orivej C'est génial! J'ai prévu d'ajouter un --pause-on-error qui, à mon avis, est la meilleure façon de procéder (lorsqu'une étape échoue, attendez une frappe avant de nettoyer, ce qui permet à l'utilisateur de se connecter et de dépanner.).

Pourriez-vous ouvrir un PR avec votre code et nous pourrons en discuter les détails.
CC @cbednarski

@vemv Je suis ce numéro depuis quelques années. Je ne peux parler que pour moi, mais je ne connais pas vraiment du tout Go, du moins pas plus que de me débrouiller et de comprendre ce que le code pourrait faire. Je ne serais pas à l'aise d'écrire du code pour quelque chose d'aussi largement utilisé que Packer, encore moins de le tester correctement.

@orivej et @ rickard-von-essen, tout ce qui nécessite une entrée de l'utilisateur ne fonctionne pas vraiment pour moi, car je n'utilise Packer que dans l'outillage automatisé (ie Jenkins ou TravisCI); Je sais qu'il y a aussi beaucoup d'autres personnes à mon poste. Je pense que ce que je voudrais vraiment, c'est quelque chose qui (1) augmente peut-être la verbosité de la sortie, et (2) laisse simplement la machine source (que ce soit EC2, VMWare, peu importe) en cours d'exécution afin qu'un humain puisse l'inspecter après le le travail a échoué.

Actuellement, le débogage s'arrêtera entre les étapes, vous obligeant à appuyer sur Entrée pour continuer, donc tant que vous savez quelle étape vous êtes sur le point d'échouer, vous pouvez simplement `` maintenir '' la VM là à des fins de débogage, mais ce n'est évidemment pas aussi bon. Vous voulez vraiment que le modèle passe par chaque étape afin que vous puissiez examiner l'état d'échec complet.

Il suffit d'ajouter mon: +1 :. Je pourrais vraiment utiliser cette fonctionnalité.

@jantman Je vais faire packer -debug ignorer le nettoyage lorsque le processus échoue et ne peut pas obtenir d'entrée (par exemple avec l'entrée de /dev/null ). Notez que la séquence d'exécution du packer est construite autour de l'idée que chaque étape peut et sera nettoyée par la suite, donc une interruption brutale laissera le système dans un état que le packer ne pourra peut-être pas gérer seul (par exemple, il se plaindra du répertoire de sortie existe déjà), vous devriez donc vous attendre à devoir trouver comment rendre votre processus répétable, mais c'est probablement facile.

@ rickard-von-essen Je vais mettre à jour mon patch (ajouter de nouveaux fournisseurs) et faire une pull request plus tard dans la journée.

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

Je construis des fenêtres sur AWS et le volume ebs "delete_on_termination" est défini sur false, donc après un échec de compilation, je peux [a] attacher le volume, [b] démarrer une instance, [c] consulter ses journaux, [d] arrêtez l'instance, [e] détachez le volume, [f] supprimez manuellement le volume.

J'ai remarqué que les fichiers c:\windows\temp<guid>.out contiennent la sortie console des approvisionneurs PowerShell que j'exécute.

Obtenir cette sortie est la seule raison pour laquelle je dois prendre toutes ces étapes supplémentaires pour obtenir ces informations.

Ce serait génial si Packer supportait quelque chose comme PACKER_CONSOLE_LOGS_COPY=$env:temp afin que ces journaux puissent toujours être rapportés (en particulier le dernier qui a échoué) et que je puisse éviter les étapes supplémentaires.

Pour ceux qui partagent mon objectif de compiler la dernière version du développeur de packer tout en intégrant le correctif précédent orivej qui s'interrompt au premier échec de la construction du packer, voici les étapes que j'ai suivies qui ont fonctionné pour moi.

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

Je peux confirmer que cela a fonctionné pour moi et que l'approvisionnement n'a été interrompu qu'en cas d'erreur.

Je n'ai pas réussi à fusionner https://github.com/orivej/packer/tree/debug-on-error-2.

Je suis curieux, je suis assez nouveau pour packer et git et ce problème; y a-t-il une autre façon dont les gens ont implémenté les correctifs d'orivej alors que j'ai décrit? Il se peut que quelque chose de très évident me manque, alors s'il vous plaît, indiquez-moi si tel est le cas.

Je vérifie simplement l'état de ce problème.

Est-ce que ce sont les changements de résolvent ce problème et qu'une pull request doit être faite? Ou est-ce que cela doit encore être résolu?

+1

ce serait vraiment utile, en ce moment j'utilise un shell en ligne avec sleep 1800 pour garder le vm en vie.
Veuillez mettre en œuvre dès que possible :)

Imho -debug fait ce dont nous avons tous besoin. Après chaque commande, vous devez appuyer sur Entrée pour passer à la suivante. Non enter = vm en vie :)

@noose - Je ne m'assois pas et ne regarde pas la construction - il y a de très longues sections en cours d'exécution (comme l'installation du serveur SQL) que je ne voudrais pas qu'il retienne pour l'entrée de l'utilisateur. Je voudrais lancer une version de test et quand j'y reviendrai, avoir quelque chose que je peux déboguer avec un minimum d'effort.

IMHO le -debug est totalement inutile. J'exécute des builds compliqués et je n'ai vraiment pas la patience d'appuyer mille fois sur Entrée jusqu'à ce que j'arrive au problème.
Je ne comprends vraiment pas pourquoi une fonctionnalité simple comme celle-ci est si difficile à implémenter.

@ henris42 alors que je suis d'accord avec vous sur l'inutilité de -debug dans ce contexte, si cela semble être une évidence, pourquoi ne pas tenter une pull request?

@noose ,
Je pense que c'est un scénario courant dans le monde DevOps :)

Il semble que tout le monde en a besoin. La construction de ces AMI est sujette aux erreurs et cette fonctionnalité rendrait le dépannage moins long

Je suis d'accord avec @worstadmin. Dans le cas de la construction de boîtes Vagrant, vous pouvez aborder le problème sous plusieurs angles (par exemple, garder la machine virtuelle autour, essayer des choses avec le provisionneur nul, etc.), alors que les images Amazon sont une race spéciale et très fastidieuse à déboguer quand il y a un problème.

Combiné avec https://github.com/mitchellh/packer/issues/1687, ce serait génial.

De plus, il est souvent utile d'ignorer les erreurs des approvisionneurs et de les laisser continuer, en particulier au début du développement d'une image, etc.

Presque 3 ans plus tard ... et toujours presque rien. J'ai passé les derniers jours à me casser la tête sur un clavier en essayant de faire des constructions de fenêtres complexes qui échouent de manière arbitraire et aléatoire à l'exécution de scripts PowerShell sans sortie et à cause du nettoyage automatique, je ne peux pas sauter sur l'instance. Lorsque je lance avec -debug activé, les "pauses" supplémentaires introduites en exigeant une entrée manuelle semblent empêcher ce problème de se produire. Ce qui, vous penseriez que cela aurait du sens, j'ajoute juste une tonne de sommeil dans mes scripts PowerShell pour simuler cela, et cela n'aide pas.

Même pas en train de mentir, je paierai à quelqu'un une prime de 100 $ si quelqu'un peut sérieusement créer une fonction - no-destroy-on-error dès que possible et lancer le bal sur un PR pour cela. J'ai (et il semble que des centaines d'autres) ont besoin de cette fonctionnalité, surtout si l'on considère que le packer est généralement utilisé avec l'automatisation à l'esprit (via CI / CD / etc.). Alors, voici mon long +1 et mon plaidoyer.

Hé, il pourrait y avoir une solution de

Je l'avais presque fonctionné aujourd'hui, mais en apprenant à Go, je ne savais pas que je vais atterrir à nouveau dans l'enfer de la métaprogrammation en poursuivant l'interface à travers plusieurs fichiers pour trouver l'implémentation :(

Consultez ma proposition actuelle au # 3885 qui me semble déjà bonne!

@tmartinx :

J'essaie de l'exécuter avec Ansible mais cela ne fonctionne pas et l'invité KVM est parti après l'erreur, donc, il n'est pas possible d'y aller pour voir ce qui ne va pas ...

Comme solution de contournement jusqu'à ce qu'il y ait une nouvelle version de packer qui contient # 3885:

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

Vous avez ensuite 4 heures pour ssh dans la VM toujours en cours d'exécution et fouiller.

Qu'est ce qui se passe ici?

• Packer a détecté une «erreur inconnue» VMware.
• _Packer_ m'a dit de vérifier le fichier journal de VMWare pour plus d'informations. Le journal est censé se trouver dans le répertoire de sortie.
• Mais _Packer lui-même_ supprime le répertoire de sortie, donc je ne peux pas vérifier le journal. Haha! Bon, Packer, vous êtes coquin!
• Des tas d'autres personnes se sont heurtées à une situation similaire, comme elles le feraient évidemment.
• Les gens ont continué à demander une solution apparemment très simple et évidente à ce problème depuis des années maintenant.
• Quelques-uns d'entre eux ont même décidé d'essayer de résoudre ce problème eux-mêmes. Il semble que leurs correctifs aient été rejetés par HashiCorp, ou peut-être qu'ils ont tout simplement échoué.
• Quoi qu'il en soit, HashiCorp a maintenu le silence radio. On dirait qu'ils ne vont tout simplement pas résoudre ce problème, jamais.

Devons-nous en conclure que le gouvernement américain a ordonné à HashiCorp de bâillonner et leur a dit de ne pas réparer cela, ou quelque chose du genre?

J'ai du mal à trouver des explications alternatives.

J'ai eu l'impression que les outils de HashiCorp sont un bon choix pour les choses DevOpsy dans l'ensemble, mais maintenant j'ai des doutes. Sérieusement. Est-ce que nous manquons tous quelque chose d'évident ici, ou HashiCorp est-il juste super loufoque?

La raison pour laquelle ce ticket est fermé est que le problème a déjà été résolu.

Ajoutez l'indicateur -on-error=ask à la ligne de commande, puis s'il y a une erreur, vous serez invité à indiquer si vous souhaitez supprimer les artefacts de construction ou non.

De plus, avant de répondre à cette question, vous pouvez ssh dans la VM et fouiller.

@ peterlindstrom234 , cela a déjà été implémenté. Vous pouvez utiliser "-on-error = abort" et le packer ne doit effectuer aucun nettoyage lorsqu'une erreur se produit.

Très bien, mon mal. Cependant, cela a pris étrangement longtemps.

@ peterlindstrom234 cela a pris du temps à cause de l'ordre de bâillon du gouvernement américain