Terraform-provider-local: Adicionada a capacidade de preservar local_file ao destruir

Olá @alanbchristie! Obrigado por esta solicitação de recurso e desculpe a demora em respondê-la.

A equipe do Terraform da HashiCorp não poderá trabalhar nisso em um futuro próximo devido ao nosso foco estar em outro lugar, mas ficaríamos felizes em revisar uma solicitação de pull se você ou outra pessoa tiver tempo e motivação para implementá-la.

Há alguns precedentes para opções como essa para recursos em que é comum usar o Terraform para criá-los, mas para passar o gerenciamento para algum outro sistema depois de um tempo. Normalmente, eles têm nomes como verb_on_destroy , onde "verbo" é uma terminologia adequada para o recurso em questão. Para essa situação, sugiro nomear o argumento delete_on_destroy , tendo como padrão true e, em seguida, ter a configuração explícita delete_on_destroy = false . Isso é consistente com outros recursos existentes semelhantes, como o argumento nomad_job deregister_on_destroy .

(A razão para a terminologia *_on_destroy aqui é que "destruir" neste contexto é a operação do Terraform, que por sua vez causa outras operações no sistema de destino. Chamá-lo do_not_destroy pode ser confuso, pois defini-lo não impedirá que o Terraform destrua a instância do recurso em si. Em vez disso, ele ajusta as ações que o Terraform executa _quando_ ele destrói a instância do recurso.)

@apparentlymart Tentei uma resolução em #10, feliz em receber qualquer feedback.

Olá,
Mesmo caso de uso e mesmo problema que @alanbchristie. alguma atualização referente a este ticket? Desde já, obrigado.

Obrigado por sua paciência @abn enquanto melhoramos nosso processo de triagem para os fornecedores da HashiCorp. Eu gostaria de entender mais sobre seu caso de uso aqui: já que você está chamando terraform destroy mas deseja preservar este recurso, ele deve ser parte de uma configuração maior com tipos adicionais de recursos que você deseja destruir. Você poderia descrever as etapas desse processo e como a configuração é usada?

@kmoe Para ser honesto, minha memória do caso de uso original é um pouco de má qualidade. Mas, como diz a descrição, o caso particular que levou a isso foi porque criamos alguns recursos na AWS que geravam tokens e/ou configurações que precisavam ser usados ​​para limpar recursos que foram criados pós-aplicação fora do tf state, que precisava ser limpo usando um playbook ansible após a chamada de destroy. O simples requisito é não poder deletar um arquivo gerado; existem vários outros casos em que isso será útil em geral.

mesmo aqui

ainda o mesmo necessário aqui

Eu adoraria dizer que ainda estou interessado neste problema, mas não estou. Em vez disso, conforme indicado no início do problema, uso o Ansible como controlador, então apenas copio o arquivo para fora do caminho do Terraform quando a infraestrutura é provisionada. Então, depois de chamar destroy, quando o controle volta para meu playbook Ansible, eu tenho o arquivo antes de sua exclusão e posso fazer o processamento necessário.

Com relação à pergunta anterior em 2020, por que alguém gostaria de manter esse arquivo? Ao contrário de outros recursos, o fato de ser um recurso "local" deve indicar que normalmente não desempenha um papel crucial na infraestrutura ... afinal, é "local" (e seria reescrito de qualquer maneira quando você executa apply ). E, talvez o fato de outros três também acharem que isso é uma boa ideia também pode indicar que, talvez, seja?

De qualquer forma - tem sido mais produtivo para mim codificar o comportamento usando uma ferramenta externa.