-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to filter/taint expired deployments to trigger recreation #473
Comments
I'm trying to implement a fix for this one:
|
So given what I've tried above, I see two solutions:
|
Signed-off-by: Jonathan Biegert <[email protected]>
Signed-off-by: Jonathan Biegert <[email protected]>
Marking this issue as stale due to inactivity. This helps us focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. |
Code of Conduct
This project has a Code of Conduct that all participants are expected to understand and follow:
Description
Our vRA imposes a lifetime on all deployments, i.e. they expire after 30 days. Afterwards the deployed VMs are powered off and not useable anymore until being deleted some time after.
For terraform, however, they still exist "in good state" -- attributes like
last_request
andlease_expire_at
tell it has been expired and allow failing such a VM early using a postcondition, but I'm looking for a way to re-create such expired deployments.Context is a scheduled CI pipeline which runs terraform followed by config management to ensure certain infrastructure (VM + application) is always present. Currently it fails in config management due to the expired VM being powered off, requiring manual destruction of the VM to recreate the setup.
This is a follow-up to #436 since even with it solved in #462 (thank you!) a workaround seems not to be possible (see hashicorp/terraform#31702).
Possible solutions
Adding a parameter to the resource (or provider?)
recreate_expired: bool
is probably the best way to goDescribe alternatives you've considered
postcondition
withself.last_request.action_id != "Deployment.Expire"
-- works, but only fails plan/apply and requires manual action to trigger recreationreplace_triggered_by
: cannot be applied to self, see linked terraform issue abovereplace_triggered_by
→data "vra_resource" { (same ID as the resource) }
(full example see linked tf issue above): data source fails when resource not yet existsReferences
Community Note
The text was updated successfully, but these errors were encountered: