Skip to content
This repository has been archived by the owner on Mar 25, 2022. It is now read-only.

volume snapshot wrongly destroyed/recreated #94

Open
cpauliat opened this issue Nov 14, 2017 · 2 comments
Open

volume snapshot wrongly destroyed/recreated #94

cpauliat opened this issue Nov 14, 2017 · 2 comments
Labels
Milestone

Comments

@cpauliat
Copy link

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.
Terraform v0.10.8

Affected Resource(s)

Please list the resources as a list, for example:

  • opc_instance
  • opc_storage_volume

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

  • opc_compute_storage_volume_snapshot

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

------ Create a storage volume

resource "opc_compute_storage_volume" "node1" {
name = "node1"
description = "Node 1 (persistent boot)"
size = 100
bootable = true
storage_type = "/oracle/public/storage/default"
image_list = "/oracle/public/OL_6.4_UEKR3_x86_64"
image_list_entry = 6
}

------ Create a non-colocated volume snapshot of this volume

resource "opc_compute_storage_volume_snapshot" "node1" {
name = "backup_node1"
description = "backup_node1"
tags = ["backup"]
collocated = false
volume_name = "${opc_compute_storage_volume.node1.name}"
}

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.
https://gist.github.com/cpauliat/15ac3450a7ac7401cd82dbc2c27c1d71

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

What should have happened?

After the successful creation of the snapshot volume with terraform apply, the next run of terraform apply should make no modification.

Actual Behavior

What actually happened?
Instead, the snapshot volume is destroyed is recreated.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply
    terraform apply --> creation of volume and snapshot volume
    terraform plan --> should show no modification, but instead shows that snapshot will be destroyed/recreated
    terraform apply --> should make no modification, but instead snapshot is destroyed/recreated.

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

  • GH-1234
@scross01
Copy link
Contributor

Add the parent_volume_bootable attribute in the opc_compute_storage_volume_snapshot resource, e.g.

resource "opc_compute_storage_volume_snapshot" "node1" {
  name = "backup_node1"
  description = "backup_node1"
  tags = ["backup"]
  collocated = false
  volume_name = "${opc_compute_storage_volume. node1.name}"
  parent_volume_bootable = "${opc_compute_storage_volume.node1.bootable}"
}

@scross01
Copy link
Contributor

There is a second related issue not explicitly covered in the example above, if there are multiple tags defined, the ordering of the tags can cause the snapshot to be recreated

resource "opc_compute_storage_volume_snapshot" "node1" {
  name = "backup_node1"
  description = "backup_node1"
  tags = ["tag2", "tag1" ]
  collocated = false
  volume_name = "${opc_compute_storage_volume. node1.name}"
  parent_volume_bootable = "${opc_compute_storage_volume.node1.bootable}"
}
$ terraform plan
...
      tags.#:                 "2" => "2"
      tags.0:                 "tag1" => "tag2" (forces new resource)
      tags.1:                 "tag2" => "tag1" (forces new resource)
...

It seem the order of the tag definitions is important. Workaround is to explicitly create a sorted list of tags in the config

resource "opc_compute_storage_volume_snapshot" "node1" {
  name = "backup_node1"
  description = "backup_node1"
  tags = "${sort(list("tag2", "tag1"))}"
  collocated = false
  volume_name = "${opc_compute_storage_volume. node1.name}"
  parent_volume_bootable = "${opc_compute_storage_volume.node1.bootable}"
}

@scross01 scross01 added the bug label Apr 4, 2018
@scross01 scross01 added this to the v1.2.0 milestone Apr 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants