provider/openstack: Acceptance Test Failures

[jtopjian]

Hello,

I noticed that the Acceptance Tests for the OpenStack provider started failing, so I wanted to fix them up.

Some have been easy enough -- just missing parameters that are now being caught or parameters that need to be Computed, but I'm having trouble with some others...

For example, the TestAccComputeV2Instance_volumeAttach runs the following:

  resource "openstack_blockstorage_volume_v1" "myvol" {
    name = "myvol"
    size = 1
  }

  resource "openstack_compute_instance_v2" "foo" {
    name = "terraform-test"
    volume {
      volume_id = "${openstack_blockstorage_volume_v1.myvol.id}"
    }
  }

and results in:

--- FAIL: TestAccComputeV2Instance_volumeAttach (63.72s)
        testing.go:137: Step 0 error: After applying this step, the plan was not empty:

                DIFF:

                UPDATE: openstack_compute_instance_v2.foo
                  security_groups.#:           "1" => "0"
                  security_groups.0:           "default" => ""
                  volume.2224808980.device:    "" => "<computed>"
                  volume.2224808980.id:        "" => "<computed>"
                  volume.2224808980.volume_id: "" => "f450c08e-c081-41af-afb7-55cebf93c24e"

                STATE:

                openstack_blockstorage_volume_v1.myvol:
                  ID = f450c08e-c081-41af-afb7-55cebf93c24e
                  attachment.# = 0
                  availability_zone = nova
                  description =
                  name = myvol
                  region = RegionOne
                  size = 1
                  snapshot_id =
                  source_vol_id =
                  volume_type = None
                openstack_compute_instance_v2.foo:
                  ID = 666daa4c-31c1-4e13-bd54-f4ff760680bd
                  access_ip_v4 = 10.1.0.168
                  access_ip_v6 = [dead:beef:4:1000:f816:3eff:fef4:921c]
                  flavor_id = 1
                  flavor_name = m1.tiny
                  image_id = 5f645a5c-9aae-41ba-897a-dbe47ca7de6d
                  image_name = Ubuntu 14.04
                  name = terraform-test
                  network.# = 1
                  network.0.fixed_ip_v4 = 10.1.0.168
                  network.0.fixed_ip_v6 = [dead:beef:4:1000:f816:3eff:fef4:921c]
                  network.0.mac = fa:16:3e:f4:92:1c
                  network.0.name = nova
                  network.0.port =
                  network.0.uuid =
                  region = RegionOne
                  security_groups.# = 1
                  security_groups.0 = default
                  volume.# = 1
                  volume.1850595663.device = /dev/vdc
                  volume.1850595663.id = f450c08e-c081-41af-afb7-55cebf93c24e
                  volume.1850595663.volume_id = f450c08e-c081-41af-afb7-55cebf93c24e

                  Dependencies:
                    openstack_blockstorage_volume_v1.myvol

The security group part is easy enough -- I just need to add the default security group to the resource.

The device and ID are indeed computed, however, the volume_id is specified.

It's looking like TypeSets that have a mixture of Computed and specified parameters are being flagged for tests?

If I run the same scenarios outside of the testing framework, everything works and the final terraform show output is correct.

Is there something I can do to get these types of test to work correctly?

[phinze]

@jtopjian thanks for looking into this!

Generally these point to problems in Create that get papered over in the subsequent Refresh that runs before Plan. You should be able to reproduce the scenario with the CLI by doing a terraform apply that creates the resource and then doing a terraform plan -refresh=false which we expect to be empty since we just applied, but as the test is telling us, that's not the case here.

Let me know if this points you in the right direction.

[jtopjian]

Indeed it did! Thank you. I was able to get this test working... onward!

I'll leave this open for now in case I have any more issues / questions.

[jtopjian]

Spoke too soon about that test. While I was able to clear all errors with the compute_instance_v2 resource, the blockstorage_volume_v1 resource began raising issues.

The problem is with the metadata parameter. Normally metadata is only defined in the resource, and thus not a computed parameter. But the block storage service will add its own metadata when a volume is attached to an instance -- notably attached_mode and readonly metadata.

So here's the situation I'm in:

• If metadata is computed and no metadata is specified in the resource, I see the following when doing a plan:

metadata.#: "" => "<computed>"

• If metadata is not computed, upon attaching a volume, the attached_mode and readonly metadata keys are correctly set, but they will be erased on the next refresh:

metadata.#:             "2" => "0"   
metadata.attached_mode: "rw" => ""   
metadata.readonly:      "False" => ""

I searched for past issues and ran into this, which looks to be very similar:

• tagsSchema should not set Computed to true #730
• Tags #731

However, it looks like that pull request just deferred the issue of allowing external updates.

Any idea how to get around this issue?

[jtopjian]

@phinze (or anyone else) Friendly poke about the metadata issue I'm seeing ... any ideas?

[phinze]

Hey @jtopjian - thanks for the ping.

I think we need Computed here so that lack of metadata in the config is not interpreted as "user wants us to make metadata empty".

As for the unresolvable .# in the plan, I fixed a possibly-related bug right around the point when you reported this issue - #1824

Are you still seeing that behavior on latest master?

[jtopjian]

@phinze Thanks for the quick reply!

Looks like your possibly-related bug was indeed related as everything is working off of the latest master. 😄

I made a few other minor changes and I'm now able to get the volume attach test to pass. I'm running the entire suite of tests through a devstack environment and, if everything passes, will submit a PR.

Thank you for your help!

[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.