-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
provisioner/chef: unregister the client from chef server when replacing an instance #3605
Comments
I left a comment about this in #386 way back in the days of three-digit issues. 😀 Right now this sort of thing is not supported by Terraform's architecture since it doesn't allow for actions on delete, but that issue #386 is about supporting that, which could then in turn solve this more-specific problem of leaving junk nodes in Chef Server. In our case we were naming the nodes after the EC2 instance id and so the outcome was hundreds of defunct nodes rather than a naming conflict, but still annoying especially since paid chef uses "number of nodes" as a quota metric. |
Isn't the destroy action on a resource exactly that? It would seem to me that what's missing is a Terraform resource that represents the membership in a chef server. Then you not only have a way to add clients, and remove clients, but also reconcile state and recover from failures. |
Does it look like this is something anyone is working on? Its a huge pain point at least for me and I would assume anyone who is using Terraform and Chef. |
@rberger no I don't think so unfortunately... It's a thing that needs to be added to Terraform core and I didn't had time to have a look at it lately... |
Just voicing my wish for this as well, currently before we can run a terraform apply we need to manually go in and delete all the registered clients in chef. |
@orclev fwiw, what I do now is append a random value from the random provider or the instance id to the end of the node name in chef. That way new instances won't conflict.
But I would like this feature instead. :) |
This should be fixed by PR #8577 which introduces a new attribute called |
Fixes hashicorp#3605 and adds the functionality suggested in PR hashicorp#7440. This PR is using a different appraoch that (IMHO) feels cleaner and (even more important) adds support for Windows at the same time.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
It would be useful to get terraform deleting the client from chef server for the instances that are being replaced. Otherwise, the replacement operation will always fail during the provisioning task because the node already exists on the chef server (assuming that you're defining the node_name)
Example:
Result:
The text was updated successfully, but these errors were encountered: