Feature Request: Uninstallation should optionally cleanup node/client data from Chef Server

[stuartpreston]

Background:
Today, the behavior seen when the Chef VM extension is uninstalled is that the configuration folder (e.g. c:\chef) remains on the VM, and the node/client keys remain on the Chef Server too.

I believe this was done originally (when the installer was bundled inside the extension) to support upgrade scenarios where we need to leave the client intact between upgrades. We then moved to a model where the installer payload did not form part of the extension bue is delivered through omnitruck.chef.io. We then never circled back to fully support a complete uninstall (including configuration). For scenarios where an external orchestrator controls the extension lifecycle, it would be useful to be able to cleanup this data.

Proposal:
Allow the extension to optionally remove the local configuration and the node/client data stored on the server as well as any local configuration on the VM.

Acceptance Criteria:

1. A new ARM property for the extension should be recognized by the extension (example/suggestion for name: destroy_client_configuration_on_uninstall - default: false to preserve existing behavior)
2. The property is then read at uninstallation time:
   • If the property is set to false (the default) then the existing logic is used, and the node/client is not removed from the Chef Server, and all local configuration is not deleted when the Extension is uninstalled.
   • If the property is set to true then the Chef client.pem should be used to make a call to the Chef Server API to delete the client and node data, and then the Chef configuration folder (e.g. c:\chef) should be deleted in its entirety.

It is likely that extending the existing Ruby inside the extension would be the best place to implement this as it has access to the various Chef client helpers that perform most of the legwork. But this is not set in stone and is an implementation detail.

[danielcbright]

Another scenario where this is helpful is when someone re-uses node names after a tear-down/rebuild. Having this ability for the Azure extension to "clean up" after itself will help to alleviate the pain caused from not being able to have the equivalent of the knife bootstrap -y option to auto-recreate nodes.