Skip to content
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

Closed
pmvilaca opened this issue Oct 22, 2015 · 9 comments · Fixed by #8577
Closed

Comments

@pmvilaca
Copy link

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:

provisioner "chef"  {
    run_list = ["role[common]"]
    node_name = "nat_instance_ffm_1a"
   ...

Result:

aws_instance.nat_1b (chef): ================================================================================
aws_instance.nat_1b (chef): Chef encountered an error attempting to create the client "nat_instance_ffm_1b"
aws_instance.nat_1b (chef): ================================================================================
@partamonov
Copy link

I guess this is related to #649 #2010 #2720. And I agree this is nice to have.

@apparentlymart
Copy link
Contributor

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.

@svanharmelen svanharmelen changed the title [feature request] [terraform-provisioner-chef] unregister the client from chef server when replacing an instance provisioner/chef: unregister the client from chef server when replacing an instance Jan 29, 2016
@dhoer dhoer mentioned this issue Feb 23, 2016
@bitglue
Copy link

bitglue commented Feb 23, 2016

not supported by Terraform's architecture since it doesn't allow for actions on delete

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.

@rberger
Copy link

rberger commented May 8, 2016

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.

@svanharmelen
Copy link
Contributor

@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...

@orclev
Copy link

orclev commented Aug 3, 2016

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.

@mtougeron
Copy link
Contributor

mtougeron commented Aug 3, 2016

@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.

  provisioner "chef" {
    node_name = "${self.name}-${self.id}"
  }

But I would like this feature instead. :)

@svanharmelen
Copy link
Contributor

This should be fixed by PR #8577 which introduces a new attribute called recreate_client. If set to true, it will first delete the existing node and client before registering the new one.

svanharmelen pushed a commit that referenced this issue Sep 15, 2016
Fixes #3605 and adds the functionality suggested in PR #7440.

This PR is using a different appraoch that (IMHO) feels cleaner and (even more important) adds support for Windows at the same time.
sharmaansh21 pushed a commit to sharmaansh21/terraform that referenced this issue Sep 15, 2016
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.
@ghost
Copy link

ghost commented Apr 22, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants