[BUG] - Editing user_data results in destroy/create op for an instance

[thehunmonkgroup]

Describe the bug

Editing user_data results in destroy/create op for an instance -- this is in contrast to the web portal, where user data can be edited in place on an already created instance.

To Reproduce

Steps to reproduce the behavior:

1. Edit user_data on an existing instance
2. run terraform plan
3. Notice that the plan calls for re-creating the instance

Expected behavior

The edit should update the user data in place.

[optik-aper]

I think this is intentional, looking at the git history and the documentation for instances. The user-data is generally only read on creation, but I can see some use-cases that do it differently. Perhaps it makes more sense to have the re-create be instigated by the user in case they need it on creation?

[thehunmonkgroup]

For reference, here's the full documentation of user_data:

(Optional) Generic data store, which some provisioning tools and cloud operating systems use as a configuration file. It is generally consumed only once after an instance has been launched, but individual needs may vary.

I can tell you that there are definitely times when user_data is read on boot, because I'm using that:

#cloud-config
manage_etc_hosts: false

This cloud-config data is read on boot, and my particular configuration disables managing the /etc/hosts file. I did not need to re-create any instances to add this configuration and make it active -- I simply needed to add the configuration to user data and reboot the server.

However, because I could not edit user data in the Terraform config without forcing a re-creation of the resource, I was forced to edit the configuration in the web console, then hand edit every single one of my Terraform state files, which is very bad practice, not to mention a PITA ;)

IMO the behavior of the web console and Terraform configuration should be identical, otherwise it is inconsistent and confusing. And because there are clear use cases for user data that do not require re-creating an instance, it seems logical to me that editing user data in place would be the correct strategy for both the web console and Terraform.

[optik-aper]

I agree and I think that we should default to this use case instead of forcing re-creation since that is something that terraform can do via configuration changes. In that case, would it be best for the terraform provider to issue a reboot to the instance if the user data is updated? I think it might be, since that's not something that terraform can easily trigger at the moment. But a warning will be necessary to avoid unexpected downtime.

[thehunmonkgroup]

In that case, would it be best for the terraform provider to issue a reboot to the instance if the user data is updated?

I think my preference would be to just update the user data, that's what happens in the web console. It sounds like there is no iron clad way that user data is used or accessed, so I wouldn't take any specific actions after the update, trusting that the sysadmin will know the best course of action.

However, I think the most important thing is to not force a re-creation of the instance.

[optik-aper]

@thehunmonkgroup I agree. That's a reasonable expectation so I'll build it to do that.