vapp property changing restarts the VM, can it work like a null provider?

[charandas]

Hi there,

Regarding the new vapp features introduced in #303 , I want to ask if there is any reason why it’s changes are tracked and require real changes?

Both coreos cloud-init and the general cloud-init are bootstrapping tools.

They are not used to introduce changes in an ongoing manner.

However, terraform still allows newer resources by changing the count parameter. What if, ones usecase is to introduce some improvements in new server’s ignition config, but handle configuration management on old servers out of band (with respect to terraform)?

I think it might be the more appropriate default setting for vapp properties to not trigger changes. If not by default, maybe users can specify whether they would like changes in their vapp properties to trigger real changes on existing resources. Just throwing some ideas there.

I always like how the null provider deals with changes. I have to explicitly taint and apply them. In vapp changes as I see them applying currently, restarting the VM may not be good for maintaining quorums of etcd, consul or zookeeper clusters.

Thoughts?

Affected Resource(s)

Please list the resources as a list, for example:

• vsphere_virtual_machine

[vancluever]

Hey @charandas, I understand the intention here of trying not to mess with existing infrastructure too much, but I don't think this is a good idea.

I don't think that this is a challenge unique to vApp properties or the vSphere provider - Terraform in general is designed around the principle of immutable infrastructure, and while we take great care to honor that while keeping reality in mind, at the end of the day one has to remember that changes to a Terraform configuration has real implications for all of the infrastructure that the configuration manages. In fact, I don't necessarily think this is a problem unique to Terraform. How you structure the configuration of a distributed system so that changes maintain quorum is something that would have to be considered for any configuration management or orchestration solution you use - be it TF, Chef, Puppet, Ansible, etc.

What I would suggest to help with this is to structure the configuration around modules. This will ultimately allow you to break out each instance without too much duplication in code. In addition to this, modules can be versioned - so you can even leave several instances on one version while modifying a few with the updated configuration you want.

Thanks and I hope that helps!

[charandas]

Thanks @vancluever for giving it your attention. I understand.

Lastly, when one sees that its going to be an in-place change, do you think an uninformed user runs the risk of saying "yes", only to realize it in-place changes the user-data but restarts the VM as a side-effect?

Could we better inform the user that it actually restarts the VM for this in-place change?

[vancluever]

Hey @charandas, the extra user feedback thing is actually something that I'd love to see in Terraform, and something that's crossed my mind before. I searched the issue tracker to see if I could find it submitted and there is an issue: hashicorp/terraform#16624. I +1'ed it for us. :)

Until this happens however it's not really possible for us to do this in a way that is going to be obvious to the user, unfortunately.

BTW: One thing I forgot about for applying, is the -target parameter. Using this you can target resources for change individually. It's not necessarily 100% what you are looking for, but might help for rolling applies.

[charandas]

Amazing @vancluever.

Both links are very helpful. Yes, using target, I can bring my instances up to date using terraform.

[amballapavankumar]

Hi @charandas / @vancluever I am trying to cloud-init from the vsphere_virtual_machine resource but its not calling that. Can you please provide me the best approach I can execute the cloud-init script from vsphere_virtual_machine?

I have attached file which contained all the steps I have followed.

Also I have tried extra_config{ "guestinfo.coreos.config.data" = "${data.template_cloudinit_config.cloudinit.rendered}" } this but not working. Please provide me your thoughts

[bpoland]

Are you using coreos or a different OS? I use this extra cloud-init provider with ubuntu, it works pretty well: https://github.com/xing/cloudinit-vmware-guestinfo

Then in the vsphere_virtual_machine you include this:

    extra_config {
        guestinfo.cloudinit.metadata = "${data.template_file.cloudinit_metadata.rendered}"
        guestinfo.cloudinit.userdata = "${data.template_cloudinit_config.cloudinit_userdata.rendered}"
    }

Unfortunately if the cloud-init data changes then the VM doesn't get redeployed (terraform just modifies the extra config on the running VM but doesn't redeploy/restart it)

[amballapavankumar]

Hi @bpoland I am using CentOS 7 and I have few questions.

1. Can you send me the sample of metadata and userdata
2. Before using extra_config { guestinfo.cloudinit.metadata = "${data.template_file.cloudinit_metadata.rendered}" guestinfo.cloudinit.userdata = "${data.template_cloudinit_config.cloudinit_userdata.rendered}" } have you installed cloud-init service and started the service?

Currently I am testing the below approach. please suggest me the changes to workout. test.txt

[amballapavankumar]

@bpoland With the vapp properties I got the below error now I am trying extra_config { guestinfo.cloudinit.userdata = "${data.template_cloudinit_config.cloudinit.rendered}" } Error:

[amballapavankumar]

Below is my cloudinit_config file cloud-config.txt

[amballapavankumar]

@bpoland I have followed your approach but looks like its not working. Please find the below logs of terraform apply

tf_apply.txt

@bpoland please help me on this

[bpoland]

Sorry I don't know if that works with centos. I have only done it with ubuntu.