F-27: enable vm config update

[treywelsh]

Allow to update CONTEXT, OS, GRAPHICS parts of a virtual machine.

Related issues: #27 #134 #63

[jaypif]

You also should update Provider doc as this is only possible from release 5.10 of OpenNebula.
Chaning context on oldest release won't have effect

[treywelsh]

The updateconf method seems a bit older than that.
It seems to be introduced by this commit: OpenNebula/one@32e1560

From version 5.0 of OpenNebula

[Th0masL]

Hi !

Thanks for this functionality, it's very much needed on my side.

Actually, it's so much needed that yesterday I did a fork of this commit ID (treywelsh:F-27-enable-vm-config-update), built the Terraform Provider from this commit, and tried to use it, but I still can't manage to update the Context values.

The Variables differences are visible in the Terraform Plan output, and it shows that it will be updated, but nothing has changed after the Terraform Apply.

I'm running on OpenNebula KVM v6.0.0.2 which is already supporting Context Update through the WebUI. Do you know if your changes are supposed to be backwards compatible with the version v6.0.0.2 ? Or are they only working with the upcoming version v6.2 ?

I'm happy to run some more tests if needed.

[jaypif]

Context update works from release 5.10. So you won't have problem with v6.

[Th0masL]

Yes, that's kind of what I was expecting, that this improvement would be "backward compatible", starting version 5.10.

That means that normally I should be able to build the Terraform Provider from this Commit ID/PR and be able to start using this functionality with my current OpenNebula KVM v6.0.0.2 installation, but that's not the case.

Have you tested it on a OpenNebula v6.0.0.2 installation ? Or are you running on the latest Master branch's commit for your testing ?

I'm happy to do some more testing and provide you with Terraform debug logs.

[treywelsh]

@Th0masL there was small mistakes in the code I didn't see (probably introduced in resolving some conflicts), I made a fix and some quick tests and it seems better now.

Thank you for your feedback and feel free to share with us if it works as expected now

[Th0masL]

Hi !

Thanks for your message.

I've tried one more time with the new changes, and I can confirm that this is working now ! Thanks !

# output of TF :
~ context       = {
          ~ "TEST_VAR"                     = "TestValue12" -> "TestValue1234"
            # (46 unchanged elements hidden)
        }
        
 # and the new value is correctly updated on the VM

One another interesting thing to note, and that might not be related to this improvement on the Context/VM Config, is that Terraform is complaining/showing that the resource role.vms[] has been edited out of Terraform, which is not true, and I get this message at every plan/apply.

That's probably due to another change that happened on the code since the release of 0.3.0.

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the
last "terraform apply":

  # module.test.module.vmgroup.opennebula_virtual_machine_group.vm-group-haproxy has been changed
  ~ resource "opennebula_virtual_machine_group" "vm-group-haproxy" {
        id          = "115"
        name        = "haproxy"
        tags        = {
            "environment" = "dev"
        }
        # (6 unchanged attributes hidden)

      ~ role {
            id                = 0
            name              = "haproxy"
          ~ vms               = [
              + 1030,
              + 1032,
            ]
            # (3 unchanged attributes hidden)
        }
    }

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

────────────────────────────────────

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.test.module.haproxy1.opennebula_virtual_machine.haproxy[0] will be updated in-place
  ~ resource "opennebula_virtual_machine" "haproxy" {
      ~ context       = {
          ~ "TEST_VAR"                     = "TestValue12" -> "TestValue1234"
            # (46 unchanged elements hidden)
        }
        id            = "1030"
        name          = "haproxy1"
        tags          = {
            "environment" = "dev"
        }
        # (17 unchanged attributes hidden)

        # (5 unchanged blocks hidden)
    }

[treywelsh]

@Th0masL:
Thank you for reporting this, I just opened a new issue to track the VM group problem: #160
Feel free to give us more details in it, this would help us to understand what happened (some simple steps to reproduce, or if it happens everytime etc.).

To answer you:
From your comment, I understand that you didn't have the vm group problem with the 0.3.0 version of the provider. Is it right ?
In this case, yes, it seems that I modified once the vm group resource to change it's behavior since 0.3.0, see #95
In brief:
At the end of the update method of the resource, there was no Read operation, I added it.
I don't think that this change is the problem, but the problem may have appeared with it.

For this PR, I'll rebase the branch and push it again.

[Th0masL]

Thanks for your message !

Yes, I can confirm that I didn't have the vm group problem with the 0.3.0 version of the provider.

I'll don't have too much information to provide, but if I do I'll add them to #160