OpenStack: plan always shows changes to resource

[JeanMertz]

What happens:

• I plan a specific (OpenStack) resource
• I apply the plan
• I plan the same resource
• Terraform tells me changes are needed

What I expected to happen:

• I plan a specific (OpenStack) resource
• I apply the plan
• I plan the same resource
• No changes should be needed

A couple of notes:

• This seems to be related to default values that I haven't set explicitly (see
  resource below)
• I've noticed this with other (but not all) OpenStack resources as well
• I have been working on a new resource (openstack_networking_port_v2), and
  have noticed that (some/all) OpenStack Go tests never fail, even when changing
  their expected outcomes

resource "openstack_networking_router_v2" "blendle" {
  name = "blendle"
  region = "${var.os_region}"
  external_gateway = "00000000-0000-0000-0000-000000000000"
}

$ terraform plan -var 'os_password=xxx' -var-file staging.tfvars -state staging.tfstate -out staging.plan -target openstack_networking_router_v2.blendle
Refreshing Terraform state prior to plan...


The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.

Your plan was also saved to the path below. Call the "apply" subcommand
with this plan file and Terraform will exactly execute this execution
plan.

Path: staging.plan

+ openstack_networking_router_v2.blendle
    external_gateway: "" => "00000000-0000-0000-0000-000000000000"
    name:             "" => "blendle"
    region:           "" => "NL"

$ terraform apply -state staging.tfstate staging.plan
openstack_networking_router_v2.blendle: Creating...
  external_gateway: "" => "00000000-0000-0000-0000-000000000000"
  name:             "" => "blendle"
  region:           "" => "NL"
openstack_networking_router_v2.blendle: Creation complete

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: staging.tfstate

$ terraform plan -var 'os_password=xxx' -var-file staging.tfvars -state staging.tfstate -out staging.plan -target openstack_networking_router_v2.blendle
Refreshing Terraform state prior to plan...

openstack_networking_router_v2.blendle: Refreshing state... (ID: f110dd4a-0f96-4675-ade9-a2aa20d45514)

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.

Your plan was also saved to the path below. Call the "apply" subcommand
with this plan file and Terraform will exactly execute this execution
plan.

Path: staging.plan

~ openstack_networking_router_v2.blendle
    admin_state_up: "true" => ""
    tenant_id:      "yyy" => ""

[JeanMertz]

I was able to "solve" most of the perceived changes by setting the default values explicitly in my resource configurations.

However, one remained, which is a value that gets set dynamically, and I can't/don't want to predict beforehand. So this certainly looks like a bug:

~ openstack_networking_subnet_v2.blendle
    gateway_ip: "10.13.1.1" => ""

there is a second one bugged right now, but that is one I build and haven't pushed a PR for yet, but here's the output anyway:

~ openstack_networking_port_v2.blendle
    mac_address: "fa:16:3e:95:06:de" => ""

[dupuy]

I am seeing this issue as well, and while specifying explicit default values helps somewhat, it is rather annoying, especially with the tenant_id argument/attribute, where changing the tenant_id is both something that is only rarely useful, but furthermore where a change from an explicit value to default/unset value (or vice versa) actually triggers a delete/create on the resource.

If the IP address of the router interface resource were available (it is visible in the OpenStack dashboard, but is not exposed as an attribute) it might be possible to make the gateway_ip argument/attribute explicit, although I suspect that doing so might create a circular dependency:

resource "openstack_networking_subnet_v2" "A" {
    gateway_ip = "${openstack_networking_router_interface_v2.B.address}" # or something like that
    ...
}
resource "openstack_networking_router_interface_v2" "B" {
    subnet_id = "${openstack_networking_subnet_v2.A.id}"
    ...
}

[jtopjian]

I think these issues were stemming from parameters that were not "computed" but should have been. There have been some recent commits that should resolve this.

WRT the tenant_id in the networking resources, I agree about this and thought about removing it altogether, but instead fixed the problem for now and will revisit it later. IMO, if the network resource should be created under a different tenant, then a different provider config should be used.

[dupuy]

I am also seeing this with OpenStack volumes and their volume_type attribute:

-/+ openstack_blockstorage_volume_v1.confluence_vdc
    attachment.#:           "1" => "<computed>"
    availability_zone:      "nova" => "nova"
    description:            "Atlassian Confluence installation & data" => "Atlassian Confluence installation & data"
    metadata.#:             "2" => "0"
    metadata.attached_mode: "rw" => ""
    metadata.readonly:      "False" => ""
    name:                   "confluence_vdc" => "confluence_vdc"
    region:                 "RegionOne" => "RegionOne"
    size:                   "50" => "50"
    volume_type:            "None" => "" (forces new resource)

I can set the availability_zone to "nova" to match the default setting (and prevent that from forcing a new resource), but when I provide explicit volume_type = "None" (or "SATA" or "SSD") it just errors on the OpenStack calls (I suspect the "None" is just a Pythonesque null reference coming back from the server side of the OpenStack REST API), so a string value of "None" from the client couldn't possibly work). This is actually worse than the tenant_id problem, because for tenant_id there is a valid value I can explicitly set - in the case of volume_type I have no way to prevent Terraform from trying to destroy and recreate the volume every time I run terraform apply. (I can prevent it from actually deleting the volumes by creating a snapshot of the volume, but it still disassociates it from the instance, which is nearly as bad - although the data is not "lost" there just isn't any access to it..)

[jtopjian]

Right, volume_type and availability_zone were changed to Computed parameters in #1897, which will cause the values to be saved properly and not show as requiring an update.

Testing on version 0.5.0, which was released prior to those changes, I'm not actually seeing the volume destroyed and recreated when doing a refresh and apply. The only issue I see is that Terraform is always reporting that values need changed. Which is annoying...

The only parameter oddity that is still left to work out is the volume attach metadata. I've reported that problem in #1830 and will make some noise about it now.

If you're seeing situations where resources are actually being destroyed and recreated (new IDs and all), can you provide a sanitized version of the Terraform configuration you're using?

Regarding volume_type in general, the value is totally dependent on the OpenStack cloud you're using. SATA and SSD are arbitrary values that may not exist. Whoever originally wrote that documentation must have had them in their cloud.

If there are no volume types defined in your cloud (which is entirely possible / normal), the value will be None. That's not very intuitive, though.

You should be able to see the volume types available to you by running:

$ nova volume-type-list

I hope that helps 😄

[jtopjian]

As a quick follow-up, #1957 should resolve the rest of the volume-related refresh issues.

[dupuy]

@jtopjian - just built terraform from master with your #1957 merged and my openstack problems are gone - thanks so much for getting this fixed so quickly, and thanks to @phinze and @mitchellh for the related work in #1824 and quick merges. I literally went to sleep at crazy o'clock (I'm in Berlin) and woke up to find the magic cyber elves had fixed my problems.

I'm still having some issues with getting openstack_compute_floatingip_v2.XXX.fixed_ip values into my DNS (cloudflare provider reports diffs didn't match during apply. This is a bug with Terraform and should be reported.) but a repeated apply solves the problem and no longer mangles the volumes or other things - I'll look into and report that issue when I get back from holidays, probably a dependency ordering thing.

[dupuy]

@JeanMertz you might want to try build from master and see if your problems are fixed too, then this could probably be closed.

[dupuy]

One more small issue (that could well be separated, as it is entirely benign), a re-apply shows a lot of meaningless changes on my security groups:

~ openstack_compute_instance_v2.confluence
    security_groups.0: "ssh-external" => "86a0dbc9-ab6d-4f66-b016-d297f04ef23f"
    security_groups.1: "default" => "e578b654-f49e-46f7-8d23-340a7109e73f"
    security_groups.2: "https-server" => "default"

~ openstack_compute_instance_v2.jira
    security_groups.0: "ssh-external" => "86a0dbc9-ab6d-4f66-b016-d297f04ef23f"
    security_groups.1: "default" => "e578b654-f49e-46f7-8d23-340a7109e73f"
    security_groups.2: "https-server" => "default"

(the ids are same as I provided on an earlier run, but the diff checker is looking at the names).

[jtopjian]

@dupuy awesome -- glad to hear things are working much better 😄

Regarding the floating IP / cloudflare issue, can you provide a sample Terraform config so I can reproduce it and work with it locally?

Regarding security groups, this might be fixed in #1848. I haven't had time to look into verifying that PR or trying to reproduce it on my end.

[jtopjian]

Unless I'm mistaken, this issue can be closed. The initial reported problems were all fixed with later PRs. Other problems mentioned later in this issue have had separate issues created.

[phinze]

Sounds good!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.