Terraform: provisioner/chef: unregister the client from chef server when replacing an instance

[pmvilaca]

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]

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

[apparentlymart]

I left a comment about this in #386 way back in the days of three-digit issues. :grinning:

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.

[bitglue]

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]

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]

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

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]

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

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.

[hashibot[bot]]

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.