Handle gracefully out-of-band destruction of volume and cloud-init resources

[dmacvicar]

Terraform states in the "Writing providers guide":

If the ID is updated to blank, this tells Terraform the resource no longer exists (maybe it was destroyed out of band). Just like the destroy callback, the Read function should gracefully handle this case.

One can as well (according to my experiment and the added tests results), implement the Exists callback, which will make terraform first check and then call Read. This is the reason why adidng graceful handling of out-of-band destruction to Domain had no effect: it already implements Exists.

This should improve the user experience by preventing the user getting errors when state is already created by terraform, but some of the resource were changed behind terraform's back.

The PR includes some commits that refactor cloud init to be more like the other resources in term of file-names, function names and reuse more of volume resource code.

Addresses #352 and probably (no evidence) related ones like #324 and #88

[multani]

YES please! :)

I implemented by trial and error something for the same problems, which I never reported upstream due to the lack of unit tests :(

I wasn't aware of Exists so I didn't try, will it bypass Read if Exists returns False?

In any case, you could have a look at my (3 lines) patch as you are setting ID to "" in the volume but not for cloud-init. I'm not sure if it's necessary or not with Exists though 🤷‍♂️

[flavio]

LGTM

[dmacvicar]

@multani Originally I implemented handling the case of removed resources on Read. Then I realized if you implement Exists terraform uses it in a way that it gracefully handles out-of-band destruction by itself. I realized because I implemented a testcase for libvirt_domain resource that I was expecting to see fail, and it didn't.

[multani]

@dmacvicar Oh I see. That's even better then!