Add update support for network block in vcd_vapp_vm, allow force guest customization

[Didainius]

Closed #299 Closes #300
This PR goes on top of https://github.com/vmware/go-vcloud-director/pull/229/files and adds two features:

• Allows updating network configuration for vcd_vapp_vm
• Introduces customization block with one field forcewhich allows to force guest customization on next terraform apply` (causing a VM to reboot).

Testing features:

• To shorten test suite length some tests will be run in parallel. A new make command make seqtestacc is introduced to force running tests sequentially

Note The customization block was introduced as there is already demand to make other customization features available as the GUI has in "Guest customization" tab. The idea is to group all customization settings under this block in future.

[vbauzys]

Maybe we should throw warning from the code? @lvirbalas

[lvirbalas]

We discussed this with Dainius Yesterday. Yes, we need, and ideally during plan, if possible, because it will rebooting VM.

[Didainius]

I have added a Terraform validator which emits warning.
Here's how the terraform plan looks like (only when customization.force=true):

...
      + template_name                  = "LB"
      + vapp_name                      = "lb-test-web"
      + vdc                            = "tf_vdc"

      + customization {
          + force = true
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Warning: Using 'true' value for field 'vcd_vapp_vm.customization.force' will reboot VM on every 'terraform apply' operation



  on main.tf line 62, in resource "vcd_vapp_vm" "web":
  62: resource "vcd_vapp_vm" "web" {



------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

When doing terraform apply however these warnings are not shown. I think I'm ok with that, but need other opinions.

The thing I like about using built in validator for warning is that it prints very nicely and points out location automatically while if I add a print to stdout manually I can't control it so nicely.

[Didainius]

Adding output for terraform validate as well:

$  terraform validate

Warning: Using 'true' value for field 'vcd_vapp_vm.customization.force' will reboot VM on every 'terraform apply' operation



  on main.tf line 62, in resource "vcd_vapp_vm" "web":
  62: resource "vcd_vapp_vm" "web" {


Success! The configuration is valid, but there were some validation warnings as shown above.

[lvirbalas]

Perfect. Does this get printed with apply without --auto-approve option too?

[Didainius]

No. That is the problem as I mentioned above.

When doing terraform apply however these warnings are not shown. I think I'm ok with that, but need other opinions.

[vbauzys]

You can write warning on apply phase using functionality from upload resource if we want that.

[Didainius]

Yes. I could, but the somewhat less nice thing is that it would be "somewhere in the middle" while the warning in validator prints it very clearly.

[Didainius]

The tests have become quite lengthy, especially with this PR so I'm experimenting with parallelizing test runs using resource.ParallelTest. During initial testing it looks as if it saves ±30mins (takes 100 mins instead of 133mins) with current commit.

[lvirbalas]

What about moving this sample to the ## Customization section below? This way it would appear contextually there where it's needed the most.

[Didainius]

True. I somehow forced myself into thinking that we put examples on top. Should be better now.

[dataclouder]

LGTM

[lvirbalas]

A good example of how seemingly small request becomes a huge PR. LGTM now!