Packer: --no-destroy-on-error como o Vagrant

Isso parece razoável. Acho que a sinalização -debug é de fato a abordagem certa aqui, mas talvez a sinalização -debug deva permitir opções como:

• Passe por cada etapa
• Continue até um erro
• Continue até que as etapas de limpeza comecem

Eu acharia a opção de continuar até um erro e não destruir a vm extremamente útil

Se alguém puder me dar algumas dicas sobre por onde começar a procurar para implementar isso, posso dedicar algum tempo para adicionar isso como uma opção

Isso seria muito útil para mim também.

@timmow você pode precisar modificar cada etapa de limpeza de criação de instância do construtor para não fazer nada se um determinado sinalizador for definido (por exemplo https://github.com/mitchellh/packer/blob/master/builder/amazon/common/step_run_source_instance.go # L122)

Seria uma certa quantidade de trabalho vasculhar todas as etapas e descobrir onde seria apropriado não agir.

Uma ideia que tive seria fornecer um sinalizador que aguardaria a entrada do usuário antes de processar qualquer etapa de limpeza. Dessa forma, você poderia executar sua depuração, pressionar Enter, por exemplo, e o empacotador cuidaria da limpeza.

Sinta-se à vontade para enviar um ping aqui se eu puder oferecer alguma ajuda.

fyi que é feito de maneira FILO aqui https://github.com/mitchellh/multistep/blob/master/basic_runner.go#L71

você pode precisar estender o runner básico (debuggable_runner?)

Seria ótimo adicionar algum tipo de funcionalidade de "pular" etapa mais abaixo, o que basicamente pularia as etapas de limpeza para esta configuração do tipo --no-destroy-on-error . Também habilitaria algumas coisas legais no modo -debug , como pressionar s para pular, interativamente.

Semelhante ao debug "pausando", acho que uma opção como -pause-on-error seria benéfica.

Olá, vejo que esse problema foi corrigido por este commit https://github.com/mitchellh/packer/commit/2ed7c3f65cc2e0a14d39d8934ef1168f8192bb08, mas não vejo a mudança no HEAD do branch master. Onde e por que desapareceu?

Eu realmente preciso disso também.

Existe alguma esperança de ter esse recurso? O que precisa ser feito para ter 2ed7c3f ou alguma variação dele mesclado?

Sim, também posso usar esta opção. Vejo que foi cometido, mas depois desapareceu.

Existe alguma atualização sobre isso?

Eu realmente adoraria isso também. Eu não posso dizer quanto tempo perdi tentando depurar problemas e tive que passar por um longo processo de criação de VM para chegar ao erro repetidamente. Ser capaz de manter a VM por perto seria uma grande vitória.

Há um ETA quando este (ou uma funcionalidade semelhante) será mesclado no principal? Estou tentando usar o Packer para construir uma VM com o Visual Studio instalado como parte da caixa Vagrant básica, e realmente preciso disso para não destruir a VM antes de ter a chance de ver por que as etapas estão falhando. Ter que reconhecer cada etapa via --debug não é aceitável.

Outro voto neste, já que a opção -debug suprime a falha que estou tentando analisar.

Gastando muito tempo tentando depurar o estado final da máquina antes que ela falhe. A opção -debug não resolve - eu quero que ele execute o processo normal e, em seguida, deixe a pasta de trabalho intacta após a falha para que eu possa diagnosticar com logs e estado. Estou realmente ansioso para algum tipo de preservação do estado de funcionamento.

Outro +1 para este recurso, seria imensamente útil.

+1 Encontrando problemas semelhantes onde seria bom depurar o estado final, ajustar alguns scripts de provisionamento e, em seguida, executar a compilação novamente para ver se isso corrigiu o processo, em vez de apertar manualmente Enter em cada etapa de depuração.

Outro + 1 para este recurso. Seria bom saber o que aconteceu com isso? Ninguém da equipe respondeu. Vá em frente, aproxime-se do prato, não dói. RI MUITO! Sou totalmente novo no Packer. Eu estava no final de uma construção ISO de 1,5 horas e isso aconteceu. O teste e a depuração devem ser fundamentais para trazer um fluxo completo de aplicativo totalmente agradável.

+1 aqui também, nós criamos nossas imagens sem cabeça, então ter --debug exigir revisão manual não é bom para nós, mas ser capaz de inspecionar a imagem defeituosa seria ótimo.

: +1: Eu também gosto de ter esse recurso

+1 Esse recurso seria ótimo!

Relacionado a ou talvez duplicado por # 1687

+1 Só poder deixar a VM como está sem deletar @error seria muito útil. Nossos scripts de instalação são bastante longos, muitos e muitos passos com o sistema atual .. :(

+1 este será muito útil

+1 para ajudar a depurar o provisionamento em caso de falha apenas com Packer

+1 estou no mesmo barco. Passei horas incontáveis ​​recriando VMs do Windows, apenas para ter um erro do Chef na etapa de provisionamento e nenhuma maneira de depurar a VM quando ela é excluída. Deixe que haja a opção de não excluir tudo durante uma falha.

Depois de ver que esse problema existe há dois anos, não tenho esperança de que seja corrigido. Estou realmente tentando gostar do Packer, mas acabo gastando mais tempo esperando pela etapa de compilação do que realmente usando os resultados.

Pleeeeeaseeeeeee +1

+1

+1

+1

Gostaria de saber qual seria o argumento para isso, encontrei este problema através do Google. Fiquei triste quando o recurso não existia.

Olá, desenvolvedores. Revisitei este tópico e posso dizer com segurança, embora tenha conseguido continuar a usar o packer de maneira eficaz, esse bug retarda seriamente o desenvolvimento de nossos sistemas. Podemos fazer isso, mas seria sinceramente bom se um funcionário pudesse fornecer alguma orientação sobre esse assunto @mitchellh. Posso até ter tempo para contribuir com uma solução se puder ser apontado na direção certa, mas vou esperar sua resposta ou alguém de sua equipe com sorte. Obrigado pela ferramenta incrível. Eu definitivamente quero que você e sua equipe saibam o quão incrível eu acho este produto.

Como me cansei de todas as notificações de e-mail +1 para um recurso que eu também queria ;-), comecei a pesquisar a base de código e adicionei uma implementação inicial. NOTA - ainda não foi testado ... e nem sei se funcionará bem. Se você tentar compilá-lo a partir do código-fonte, encontrei um problema interessante com a auto-referência do Packer no github, que fará com que este código não seja compilado corretamente. Você precisará vincular temporariamente a pasta de origem do empacotador no GoPath à pasta para a qual baixou este repositório (ou espere que eu teste e envie uma solicitação de pull).

https://github.com/jcoutch/packer

O fato de que este não é o comportamento padrão, com o perdão do meu francês, é completamente insano. Cometeu um erro de digitação em seu script de instalação? Bem, vamos simplesmente _destruir todo o seu trabalho e nunca lhe devolver aquela hora da sua vida. Sobre. E acabou. Novamente._

Eu imagino que _literalmente cada pessoa_ que usa essa ferramenta para qualquer coisa além dos exemplos mais simples está enfrentando esse problema _ toda vez que a usa_. Claramente, há uma demanda massiva por esse recurso, mas ainda não foi implementado, 2 anos depois.

Absolutamente impressionante.

+1

Cara, esse foi um comentário sarcástico. Mau humor ontem, mas toda essa perda de tempo está começando a custar muito tempo e dinheiro.

@jcoutch - você tem uma construção que possa compartilhar?

Eu tenho um OSX construído em minha máquina, mas não tive a chance de testar se ele
funciona ainda. Trabalhando nisso em meu tempo livre ... que eu não tive muito que
poupar ultimamente. Sem mencionar que esta é minha primeira experiência com Go (bastante
uma linguagem interessante.) Vou tentar testá-lo até o final desta semana,
e se tudo estiver certo, enviarei uma solicitação de pull. Eu também vou tentar
postar compilações do OSX e do Windows para que outros testem quando eu souber que está estável.

Na quarta-feira, 23 de setembro de 2015, 17:14, Rich Jones [email protected] escreveu:

Cara, esse foi um comentário sarcástico. Mau humor ontem, mas todo esse tempo
o desperdício começa a custar muito tempo e dinheiro.

@jcouth - você tem uma construção que possa compartilhar?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -142730452.

Pleeeease !! :-D

Estou tentando rodar com o Ansible mas não funciona e o guest KVM sumiu depois do erro, então não dá pra ir lá ver o que está errado ...

Felicidades!

Muito necessário. Obrigado.

Aqui está o patch @jcoutch com terminações de linha adequadas para uma revisão mais fácil: https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

Esse patch impede a exclusão apenas se os pré-processadores falharem, ele não mantém os artefatos quando um construtor (com seus provisionadores) falha.

EDIT: Essa parece ser a intenção, mas na verdade não faz nada, embora pudesse ser facilmente consertado para atendê-la.

Sim, eu não tive a chance de responder a este tópico. Eu finalmente tentei
minhas alterações com um provisionador em queda ... não funciona como eu
pretendido. Olhando mais profundamente no código, parece que o construtor lida com
a exclusão de artefatos em uma falha de provisionamento ... em vez do código I
modificado.

No sábado, 3 de outubro de 2015, 9h37, Orivej Desh [email protected] escreveu:

Aqui está @jcoutch https://github.com/jcoutch patch com linha adequada
terminações para revisão mais fácil: orivej @ 23bbd4d
https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -145249481.

Aqui https://github.com/orivej/multistep/commit/e02bce9811c65138ea2e84c7162cd8769f35858f é uma prova de conceito que redefine --debug para parar apenas uma vez, após a primeira falha. Requer https://github.com/mitchellh/multistep/pull/5 para parar antes da primeira limpeza, em vez de antes da segunda limpeza. Este comportamento foi proposto em # 1687. (Esta não é uma prova de conceito, mas uma solução se redefinir --debug como proposto em # 1687 estiver OK.)

+1 para preservar artefatos em uma compilação com falha no modo de depuração.

Estou executando o packer por um tempo com o patch e nunca tive um motivo para iniciá-lo sem -debug . Eu me pergunto se devo publicar binários para testes mais amplos.

+1

Acabei de notar que o link que postei era um patch para várias etapas, não para o empacotador. A correção que faz o empacotador pausar em caso de erro ao executar com -debug está em https://github.com/orivej/packer/tree/debug-on-error

@orivej com qual patch devo começar se quiser testar seu patch de comportamento sem destruição? https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ?

Sim, existe um commit, orivej @ a713a46. Ele ainda pode ser rebaseificado de forma limpa no master.
Você também precisa de um patch para github.com/mitchellh/multistep de https://github.com/mitchellh/multistep/pull/5 , ou o empacotador fará uma pausa após destruir a última etapa.

@orivej você tem um binário corrigido para OSX? Reiniciar todo o processo de construção devido a um pequeno erro ao construir uma máquina do Gentoo Linux é incrivelmente doloroso (demorado). Ter a possibilidade de carregar a caixa após a falha e descobrir o que há de errado é uma obrigação para mim.

Eu adicionei uma opção para repetir a etapa com falha em vez de abortar, embora mesmo se isso for bem-sucedido, a compilação geral pode falhar; e, se eu não errar, o empacotador não processa a entrada de forma confiável e o usuário pode ter que responder várias vezes.

Esta mudança não depende de várias etapas corrigidas e vive no branch , commit .

Carreguei os binários aqui: https://orivej-packer.s3.amazonaws.com/index.html (subárvore debug-on-error-2 ).

Ter a possibilidade de carregar a caixa após a falha e descobrir o que há de errado é uma obrigação para mim.

Meu patch não preserva a caixa que pode ser carregada, mas em vez disso, deixa a caixa atual viva até que você termine manualmente a compilação, de modo que você possa fazer SSH nela e executar a depuração (ao chamar packer com -debug opção

Obrigado pelo feedback, @orivej.

Meu patch não preserva a caixa que pode ser carregada, mas, em vez disso, deixa a caixa atual ativa até que você termine manualmente a compilação, para que você possa fazer SSH nela e executar a depuração (ao chamar o packer com a opção -debug).

Observe que a construção do empacotador padrão, com --debug , faz uma pausa antes que o ambiente seja destruído, dando a você a opção de depurá-lo conforme descrito. Para fazer isso, uso "headless": false . Quão diferente é o processo com seu patch?

• Isso faz com que o empacotador pause somente depois que uma etapa falhar, em vez de pausar após cada etapa.
• Ele faz uma pausa antes do empacotador limpar após a etapa com falha. (Embora eu não me lembre por que precisei disso, já que a etapa de provisionamento mais problemática não faz nenhuma limpeza.)
• A segunda edição do patch permite repetir a etapa que falhou. (Quando o provisionamento falha, todos os provisionadores são executados novamente.)

Acabei de notar que o # 2608 tomou uma decisão infeliz de priorizar plug-ins de versões mais antigas do packer para plug-ins integrados mais novos, então para usar minha compilação do packer (ou versões futuras do packer, a menos que os autores reconsiderem esse comportamento), você precisa remover todos binários cujos nomes começam com packer- .

Manipulação de entrada não confiável também é um artefato de # 2608, vou ver se consigo consertá-lo.

O tratamento de entrada não confiável é causado pela inicialização extra de plug-ins integrados, em particular por setupStdin() em main.go . Uma vez que esta chamada parece ser incapaz de servir ao seu propósito declarado de qualquer maneira, fui capaz de desativá-la sem repercussões e reconstruir meus binários.

Ser simplesmente capaz de sair do empacotador sem parar ou destruir a VM em caso de erro seria muito útil. Isso é particularmente importante nos componentes de provisionamento que geralmente contêm a lógica mais customizada. Ser capaz de conectar o SSH em uma caixa e executar novamente o script original ou tentar um script modificado ou receita para teste pode fornecer insights rápidos e valiosos sobre o que realmente causou o erro e qual é a correção. Fazer uma compilação inteira do packer consome muito tempo para exigi-lo até mesmo para a solução de problemas mais simples.

O sinalizador -debug é útil, mas torna o processo muito manual. Muitas vezes, é útil executar uma compilação autônoma, mas fazer com que ela seja encerrada quando encontrar um erro e deixe o sistema em um estado que permite a investigação da causa e a correção.

: +1: independentemente de -debug passar ou falhar, deve haver uma opção para manter a instância em execução para que você possa reproduzir scripts / depurar na instância, etc. A menos que isso de alguma forma interfira na captura da imagem AMI.

+1

1 .. Estou surpreso que isso aconteceria cerca de 2,5 anos depois, pois seria tão útil. Isso tornaria minha vida muito mais fácil solucionar problemas de minha compilação do Packer.

Consegui superar isso na AWS usando proteção de terminação na instância antes do chef-cliente iniciar. não é uma opção decente, mas funciona. Quaisquer outras opções :)

+500 - por que esse recurso ainda não está disponível?

Talvez nós, como desenvolvedores, possamos tentar sujar as mãos em vez de reclamar?

A solicitação de recurso não poderia ser mais simples.

• Leia uma nova opção de linha de comando ( --no-destroy-on-error )
• Adicione um humilde if no lugar certo. Pseudo-código:

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

Vou tentar. E se funcionar, eu não vou compartilhar (principalmente para evitar solicitações / reclamações hipotéticas). O esforço é uma coisa boa.

@vemv , eu já resolvi essencialmente esse problema com dois commits em https://github.com/orivej/packer/commits/debug-on-error-2.

@orivej Isso é incrível! Tenho planejado adicionar um --pause-on-error que acho que é a melhor maneira de fazer (quando uma etapa falhar, espere por um pressionamento de tecla antes de limpar, permitindo que o usuário faça o login e resolva o problema).

Você poderia abrir um PR com seu código e podemos discutir os detalhes lá.
CC @cbednarski

@vemv Venho acompanhando esse assunto há alguns anos. Só posso falar por mim, mas realmente não conheço Go, pelo menos não mais do que vasculhar e descobrir o que o código pode fazer. Eu não me sentiria confortável escrevendo código para algo tão amplamente usado como o Packer, muito menos testando-o adequadamente.

@orivej e @rickard-von-essen, qualquer coisa que requeira entrada do usuário realmente não funciona para mim, já que eu só uso o Packer em ferramentas automatizadas (por exemplo, Jenkins ou TravisCI); Eu sei que há muitas outras pessoas na minha posição também. Acho que o que eu realmente quero é algo que (1) talvez aumente o detalhamento da saída e (2) apenas deixe a máquina de origem (seja EC2, VMWare, seja o que for) em execução para que um humano possa inspecioná-la após o trabalho falhou.

Atualmente, a depuração fará uma pausa entre as etapas, exigindo que você pressione Enter para continuar, então, desde que você saiba em qual etapa está prestes a falhar, você pode simplesmente 'manter' a VM lá para fins de depuração, mas obviamente isso não é tão bom. Você realmente deseja que o modelo passe por todas as etapas para que possa examinar todo o estado de falha.

Apenas adicionando meu: +1 :. Eu realmente poderia usar esse recurso.

@jantman Farei com que packer -debug pule a limpeza quando o processo falhar e não puder obter entrada (por exemplo, com entrada de /dev/null ). Observe que a sequência de execução do empacotador é construída em torno da ideia de que cada etapa pode e será limpa posteriormente, então o encerramento abrupto deixará o sistema em um estado que o empacotador pode não ser capaz de lidar por conta própria (por exemplo, ele reclamará do diretório de saída já existe), então você deve esperar ter que descobrir como tornar seu processo repetível, mas isso é provavelmente fácil.

@rickard-von-essen Vou atualizar meu patch (adicionar novos provedores) e fazer uma solicitação de pull ainda hoje.

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

Estou construindo caixas do Windows na AWS e tenho o volume ebs "delete_on_termination" definido como falso para que, após uma construção com falha, eu possa [a] anexar o volume, [b] inicializar uma instância, [c] olhar seus logs, [d] desligue a instância, [e] desconecte o volume, [f] exclua manualmente o volume.

Notei que os arquivos c:\windows\temp<guid>.out contêm a saída do console dos provisionadores do PowerShell que executo.

Obter essa saída é a única razão pela qual tenho que realizar todas essas etapas extras para obter essas informações.

Seria ótimo se o Packer suportasse algo como PACKER_CONSOLE_LOGS_COPY=$env:temp para que esses logs sempre pudessem ser trazidos de volta (especialmente o último que falhou) e eu pudesse evitar as etapas extras.

Para aqueles que compartilham meu objetivo de compilar o lançamento de desenvolvimento do empacotador mais recente e, ao mesmo tempo, integrar a correção anterior do orivej que pausa na primeira falha da construção do empacotador, aqui estão as etapas que executei e que funcionaram para mim.

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

Posso confirmar que isso funcionou para mim e o provisionamento só foi interrompido quando houve um erro.

Não consegui mesclar https://github.com/orivej/packer/tree/debug-on-error-2.

Estou curioso, sou bastante novo no packer, no git e neste problema; Existe alguma outra maneira que as pessoas têm implementado as correções do orivej, então como eu descrevi? Posso estar faltando algo muito óbvio, então, por favor, me dê uma dica se for o caso.

Apenas verificando o estado desse problema.

É que as mudanças de

+1

seria muito útil, agora estou usando um shell embutido com sleep 1800 para manter o VM vivo.
Por favor, implemente o mais rápido possível :)

Imho -debug está fazendo o que todos nós precisamos. Após cada comando, você precisa pressionar enter para prosseguir com o próximo. Não entrar = vm alive :)

@noose - eu não sento e vejo a construção - há algumas seções de execução muito longa (como a instalação do servidor SQL) que eu não gostaria que ele retivesse para entrada do usuário. Eu gostaria de iniciar um teste de compilação e, quando voltar, tenho algo que possa depurar com o mínimo de esforço.

IMHO o debug é totalmente inútil. Estou executando compilações complicadas e realmente não tenho paciência de pressionar Enter mil vezes até chegar ao problema.
Eu realmente não entendo por que um recurso básico como esse é tão difícil de implementar.

@ henris42 embora eu concorde com você sobre a inutilidade de -debug neste contexto, se parece tão óbvio, por que você não dá uma chance a um pedido de pull?

@noose , eu automatizo a construção do empacotador em um trabalho do Jenkins (que extrai do Git o config / scripts e os playbooks do Ansible). Usando o packer dessa forma, um modo interativo não é útil; é muito mais útil uma análise pós-falha.
Acho que este é um cenário comum no mundo DevOps :)

Parece que todo mundo precisa disso. Construir esses AMIs é propenso a erros e esse recurso tornaria menos demorado para solucionar

Eu concordo com @worstadmin. No caso de construir caixas Vagrant, você pode resolver o problema de vários ângulos (por exemplo, manter a máquina virtual por perto, tentar coisas com o provisionador nulo, etc.), enquanto as imagens da Amazon são uma raça especial e muito cansativas para depurar quando há um problema.

Combinado com https://github.com/mitchellh/packer/issues/1687, isso seria ótimo.

Além disso, geralmente é útil ignorar os erros dos provisionadores e permitir que isso continue, especialmente durante o estágio inicial de desenvolvimento de uma imagem, etc.

Quase 3 anos depois ... e ainda quase nada. Passei os últimos dias esmagando minha cabeça em um teclado tentando fazer compilações complexas do Windows que arbitrariamente e aleatoriamente falham na execução de scripts do PowerShell sem saída e por causa da limpeza automática, não consigo pular para a instância. Quando executo com -debug habilitado, as "pausas" extras introduzidas pela necessidade de entrada manual parecem fazer com que esse problema não ocorra. O que, você pensaria que faria sentido, eu apenas adicionei uma tonelada de dormentes em meus scripts do PowerShell para simular isso, e isso não ajuda.

Sem nem mesmo mentir, pagarei a alguém uma recompensa de $ 100 se alguém puder seriamente criar um recurso --no-destroy-on-error o mais rápido possível e fazer a bola rolar em um PR para isso. Eu (e parece que centenas de outros) preciso desse recurso, especialmente quando se considera que o empacotador geralmente é usado com a automação em mente (via CI / CD / etc). Então aqui está meu longo +1 e apelo.

Ei, pode haver uma solução alternativa para um provisionador de shell, mas não tenho ideia sobre outros provisionadores. : cry_cat_face:

Estava quase funcionando hoje, mas aprendendo a usar Go não sabia que voltaria a cair no inferno da metaprogramação, perseguindo a interface por meio de vários arquivos para encontrar a implementação :(

Confira minha proposta atual em # 3885 que já me parece boa!

@tmartinx :

Estou tentando rodar com o Ansible mas não funciona e o guest KVM sumiu depois do erro, então não dá pra ir lá ver o que está errado ...

Como solução alternativa até que haja uma nova versão do empacotador que contenha # 3885:

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

Você terá então 4 horas para entrar na VM ainda em execução e vasculhar.

Que diabos está acontecendo aqui?

• O empacotador detectou um VMware 'Erro desconhecido'.
• _Packer_ me disse para verificar o arquivo de log do VMWare para obter mais informações. O log deve estar no diretório de saída.
• Mas o próprio _Packer_ exclui o diretório de saída, então não posso verificar o log. Haha! Boa, Packer, seu malandro!
• Um monte de outras pessoas se depararam com uma situação semelhante, o que obviamente aconteceria.
• As pessoas continuam solicitando uma solução aparentemente muito simples e acéfala para esse problema _ há anos_.
• Alguns deles até decidiram tentar consertar sozinhos. Parece que seus patches foram rejeitados pela HashiCorp, ou talvez eles simplesmente não tiveram sucesso.
• De qualquer forma, a HashiCorp manteve silêncio de rádio. Parece que eles não vão consertar isso nunca.

Devemos concluir que o governo dos EUA ordenou a HashiCorp e disse a eles para não consertar isso ou algo assim?

Estou tendo dificuldade em encontrar explicações alternativas.

Tive a impressão de que as ferramentas da HashiCorp são uma boa escolha para o DevOpsy em geral, mas agora estou tendo dúvidas. A sério. Todos nós estamos perdendo algo óbvio aqui, ou a HashiCorp está apenas sendo super obscura?

O motivo pelo qual este tíquete foi fechado é porque o problema já foi corrigido.

Adicione o sinalizador -on-error=ask à linha de comando e, se houver um erro, você será perguntado se deseja excluir os artefatos de construção ou não.

Além disso, antes de responder a esta pergunta, você pode usar o ssh na VM e vasculhar.

@ peterlindstrom234 , isso já foi implementado. Você pode usar "-on-error = abort" e o empacotador não deve realizar nenhuma limpeza quando ocorrer um erro.

Tudo bem, meu mal. Porém, com certeza demorou estranhamente.

@ peterlindstrom234 demorou muito por causa da ordem de silêncio do governo dos EUA