Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.0.2 always shows changes - adds template_tags #369

Closed
jaket91-1 opened this issue Nov 9, 2022 · 4 comments · Fixed by #378
Closed

v1.0.2 always shows changes - adds template_tags #369

jaket91-1 opened this issue Nov 9, 2022 · 4 comments · Fixed by #378

Comments

@jaket91-1
Copy link

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

$ terraform -v
Terraform v1.3.1
on darwin_amd64

Affected Resource(s)

  • opennebula_virtual_machine

Terraform Configuration Files

resource "opennebula_virtual_machine" "server" {
  count          = var.vmcount
  name           = var.vmname
  cpu            = var.cpu
  vcpu           = var.vcpu
  memory         = var.memory
  group          = var.group
  permissions    = "660"
  on_disk_change = "recreate" # Tell Terraform to recreate the VM if the disk need to be updated

  # from here https://github.com/OpenNebula/terraform-provider-opennebula/blob/a6c428b07da88b89019b7dd374a343f5955e48b3/opennebula/resource_opennebula_virtual_machine_test.go#L793-L795
  cpumodel {
    model = "host-passthrough"
  }

  context = {
     <CUSTOM TAGS>
  }

  vmgroup {
    vmgroup_id = var.vmgroup_id
    role       = var.vmgroup_role
  }

  os {
    arch = "x86_64"
    boot = "disk0"
  }

  disk {
    image_id = var.image_id
    size     = var.disksize
    target   = "vda"
    driver   = "qcow2"
  }
  
  nic {
    network_id      = var.nicnetwork_id
    ip              = var.nicip
    security_groups = var.sgs
  }

  nic {
    network_id      = var.nicnetwork_id-2
    ip              = var.nicip-2
    security_groups = var.sgs-2
  }

  tags = {
    environment = var.tagsenv
  }

  graphics {
    type   = "VNC"
    listen = "0.0.0.0"
  }

  lifecycle {
    create_before_destroy = false
  }

}

Debug Output

  • After applying, the template_tags is in the state file with a null value
$ cat /tmp/terraform.tfstate | grep template_tags  | head -1
            "template_tags": null,

Expected Behavior

  • Plan shows the below:
No changes. Your infrastructure matches the configuration.

Actual Behavior

  • Plan always shows an addition of template_tags despite being in the state file with a null value
  # module.server["server"].opennebula_virtual_machine.server[0] will be updated in-place
  ~ resource "opennebula_virtual_machine" "server" {
        id             = "479"
        name           = "server"
        tags           = {
            "environment" = "stage"
        }
      + template_tags  = (known after apply)
        # (22 unchanged attributes hidden)

        # (7 unchanged blocks hidden)
    }

Steps to Reproduce

  • We are trying to upgrade from version 0.4.3 to 1.0.2
  • This behaviour was not present in provider version 0.4.3, a subsequent apply would show no changes.

Important Factoids

  • We are not using VM templates
  • After destroying and applying, the state file shows a none null value and subsequent plan/apply show no changes
$ cat /tmp/terraform.tfstate | grep template_tags | head -1
            "template_tags": {},
@treywelsh
Copy link
Collaborator

treywelsh commented Nov 9, 2022

Did you compiled the 1.0.2 release ?
The 1.0.2 doesn't seems available in the registry: https://registry.terraform.io/providers/OpenNebula/opennebula/

And just to be sure, all the steps you show were made with the 1.0.2 release of the provider ? (or did you create the resource with the 0.4.3 ? )
You mentionned a version upgrade in the Steps to Reproduce section.

@jaket91-1
Copy link
Author

Did you compiled the 1.0.2 release ? The 1.0.2 doesn't seems available in the registry: https://registry.terraform.io/providers/OpenNebula/opennebula/

  • We have a local provider configured and simply copied the zip files from the 1.0.2 release to our local copy.

And just to be sure, all the steps you show were made with the 1.0.2 release of the provider ? (or did you create the resource with the 0.4.3 ? ) You mentionned a version upgrade in the Septs to Reproduce section.

  • Good point, should have said. Yes, the resources were created with version 0.4.3 of the provider.

@github-actions
Copy link

This issue is stale because it has been open for 30 days with no activity and it has not the 'status: confirmed' label or it is not in a milestone. Remove the 'status: stale' label or comment, or this will be closed in 5 days.

@treywelsh
Copy link
Collaborator

treywelsh commented Dec 13, 2022

This make me think to #312 issue with template_disk and template_nic sections. It's the same kind of behavior.
I made a comment in a related PR #378:

Until now template_id, template_disk, template_nic are filled at virtual machine creation when instantiating
a VM from a template. After that they don't change because they reflect the template used at the VM creation.

Same comment apply for template_tags: this attribute reflect the (partial) content of the template from which the VM is instantiated, at the time of the instantiation.
After the instantiation the template is a resource that may evolve but these changes don't have any effect on the running VM.
So, after the creation we don't read anymore these attributes.

So, template_tags show a diff at each step because there was no create step made with the 1.0.2 release of the provider
and then template_tags was never filled.
And then all next read steps made with the 1.0.2 release don't modify the template_tags content.

To get rid of this diff, either modify the state manually to add an empty value for template_tags, or I'll see if I can add some code to fill these attributes at read step with something empty like I tried to do in #378 for template_nic and template_disk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants