-
Notifications
You must be signed in to change notification settings - Fork 59
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
feature-request: Delayed destruction #162
Comments
Hi All, After a few hours round-the-bin with internal support here at VMware, they've concluded there is little they are able to do unless there are logs associated with failed deployments. I am going to submit a PR to make the destruction of vSphere environments dependent upon an environment variable. The default value will be to not destroy the environment. |
Reference pull request for skipping destroy #163 |
Please change the default to be destroy. If an environment variable VSPHERE_DESTROY_SKIP is set to Ideally this can be applied to all providers. Then we can turn on skipping cleanup when we want to debug. Summary:
|
Hi @taylor, Thank you for your feedback. Done and done. I also made it so |
This patch introduces the environment variable `VSPHERE_DESTROY_SKIP`. If set to `true` the deployed environment will not be deleted during the destroy step. This PR fixes crosscloudci#162 and is related to crosscloudci#161; possibly crosscloudci#154.
Hi All,
Due to some previous issues, as well as the current #161, we're trying to figure out the best method to delay the destruction of our environments. PR #154 provides the ability to destroy an environment without the need for the Terraform state, so one method would be to simply disable the destroy step for vSphere and let us manually remove resources a day or two later.
However, I think this is a feature that may also add value to other platforms. The fact is, it's hard to debug failed deployments when the resources are no longer present. Logs may be attached to those resources, and when the resources are destroyed, so too are the logs.
This is potentially a priority issue for VMware.
Thank you!
The text was updated successfully, but these errors were encountered: