Terraform-provider-local: Möglichkeit hinzugefügt, local_file beim Zerstören beizubehalten

Hallo @alanbchristie! Vielen Dank für diese Funktionsanfrage und entschuldigen Sie die Verzögerung bei der Beantwortung.

Das Terraform-Team von HashiCorp wird in naher Zukunft nicht daran arbeiten können, da wir uns woanders konzentrieren, aber wir würden gerne einen Pull-Request prüfen, wenn Sie oder jemand anderes die Zeit und Motivation hat, ihn zu implementieren.

Es gibt einige Präzedenzfälle für Optionen wie diese für Ressourcen, bei denen es üblich ist, Terraform zu verwenden, um sie zu erstellen, aber die Verwaltung nach einer Weile an ein anderes System zu übergeben. Normalerweise haben diese Namen wie verb_on_destroy , wobei "Verb" eine geeignete Terminologie für die betreffende Ressource ist. Für diese Situation würde ich vorschlagen, das Argument delete_on_destroy zu benennen, es standardmäßig auf true zu setzen und dann die explizite Konfiguration delete_on_destroy = false zu haben. Dies steht im Einklang mit anderen ähnlichen vorhandenen Funktionen wie dem Argument nomad_job deregister_on_destroy .

(Der Grund für die *_on_destroy -Terminologie hier ist, dass „destroy“ in diesem Zusammenhang die Operation von Terraform ist, die wiederum andere Operationen im Zielsystem verursacht. Die Bezeichnung do_not_destroy könnte verwirrend sein, da sie festgelegt wurde wird Terraform nicht wirklich daran hindern, die Ressourceninstanz selbst zu zerstören. Stattdessen passt es die Aktionen an, die Terraform ergreift, _wenn_ es die Ressourceninstanz zerstört.)

@apparentlymart Ich habe eine Auflösung in Nr. 10 versucht und nehme gerne Feedback entgegen.

Hallo,
Gleicher Anwendungsfall und gleiches Problem wie @alanbchristie. Irgendwelche Updates zu diesem Ticket? Vielen Dank im Voraus.

Vielen Dank für Ihre Geduld @abn , während wir unseren Triage-Prozess für die HashiCorp-Anbieter verbessern. Ich würde gerne mehr über Ihren Anwendungsfall hier erfahren: Da Sie terraform destroy aufrufen, aber diese Ressource erhalten möchten, muss sie Teil einer größeren Konfiguration mit zusätzlichen Arten von Ressourcen sein, die Sie zerstören möchten. Könnten Sie die Schritte dieses Prozesses und die Verwendung der Konfiguration skizzieren?

@kmoe Ehrlich gesagt ist meine Erinnerung an den ursprünglichen Anwendungsfall etwas dürftig. Aber, wie die Beschreibung sagt, der spezielle Fall, der dazu führte, war, dass wir einige Ressourcen auf AWS erstellt haben, die Token und/oder Konfigurationen generierten, die verwendet werden mussten, um Ressourcen zu bereinigen, die nach der Anwendung außerhalb erstellt wurden tf state, der mit einem ansiblen Playbook bereinigt werden musste, nachdem destrue aufgerufen wurde. Die einfache Anforderung besteht darin, eine generierte Datei nicht löschen zu können; Es gibt verschiedene andere Fälle, in denen dies im Allgemeinen nützlich sein wird.

Hier gilt das gleiche

noch das gleiche hier benötigt

Ich würde gerne sagen, dass ich mich immer noch für dieses Problem interessiere, aber das bin ich nicht. Stattdessen verwende ich, wie zu Beginn des Problems angegeben, Ansible als Controller, sodass ich die Datei einfach aus dem Weg von Terraform kopiere, sobald die Infrastruktur bereitgestellt ist. Nachdem ich „destroy“ aufgerufen habe und die Steuerung wieder zu meinem Ansible-Playbook wechselt, habe ich die Datei vor dem Löschen und kann die erforderliche Verarbeitung durchführen.

In Bezug auf die frühere Frage im Jahr 2020, warum jemand eine solche Akte führen möchte? Im Gegensatz zu anderen Ressourcen sollte die Tatsache, dass es sich um eine "lokale" Ressource handelt, darauf hindeuten, dass sie normalerweise keine entscheidende Rolle innerhalb der Infrastruktur spielt ... sie ist schließlich "lokal" (und würde sowieso umgeschrieben werden, wenn Sie apply ausführen

Wie auch immer - es war für mich produktiver, das Verhalten mit einem externen Tool zu codieren.