Feature request: Add Chef *provider* (not provisioner)

[dupuy]

When re-creating infrastructure I have found that the previously created Chef node prevents the recreated instance from registering using the Chef organization validator:

=============================================================================
Chef encountered an error attempting to create the client "test-int"
=============================================================================

Authorization Error:
--------------------
Your validation client is not authorized to create the client for this node (HTTP 403).

Possible Causes:
----------------
* There may already be a client named "test-int"

I am not using the Chef provisioner as I would prefer to not have shared/fixed SSH keys for the instance, but am rather using cloud-init to install Chef and register with the Chef server. I don't know if this problem would still occur if I was using the Chef provisioner, but suspect it would.

I can of course manually delete the client from my Chef server before applying a plan that re-creates the instance, but it would be nicer for this to be automated, by having a Chef provider that allows me to specify the Chef node attributes (e.g. run list) and making that resource dependent on the actual compute instance resource, so that it is destroyed before the compute instance, allowing a re-created instance to be able to register using the validator.

In my (cloud-init) case, having the run-list in a separate Chef resource would also have the advantage that I would be able to configure that directly in my Terraform source (using the cloud-config user-data would force recreation of the compute instance every time the run-list changed, so I am planning to muck up something that will set the runlist using meta-data instead, but this is extra work).

[svanharmelen]

@dupuy when using the Chef provisioner you would (currently) indeed have the same issue. I think the best solution for this would be to make provisioners (in general) able to execute actions when destroying an instance.

There is already some ongoing discussion around this: #649

So when this feature is in, we could extend the Chef provisioner to delete a node in Chef Server when the instance is destroyed. And in your use case when using cloud-init, you could add a custom knife command using a local-exec provisioner to do the same using knife when an instance is destroyed.

[phinze]

I agree with @svanharmelen that the way to solve this is with a first-class ability to execute provisioners on resource destroy, which we're tracking in the other issue. @ndarilek feel free to follow up here if you'd like to discuss further! 👍

[ghost]

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.