terraform-provider-openstack: Floating IP not getting associate to instances in sequential manner

This issue was originally opened by @rp85 as hashicorp/terraform#20003. It was migrated here as a result of the provider split. The original body of the issue is below.

Terraform Version

0.11.10

Openstack plugin Version v1.13.0

Terraform Configuration Files

resource "openstack_blockstorage_volume_v2" "system" {
  count = "${var.num}"
  region = "RegionOne"
  name  = "${format("rootvol-test-%02d", count.index + 1)}"
  size = 50
  image_id = "${var.openstack_image_id}"
}

resource "openstack_blockstorage_volume_v2" "volumes" {
  count = "${var.num}"
  name  = "${format("datavol-test-%02d", count.index + 1)}"
  size  = 100
}

resource "openstack_compute_instance_v2" "push" {
  count = "${var.num}"
  name = "${format("Test-%02d", count.index+1)}"
  availability_zone = "${element(var.az_list, count.index)}"
  flavor_name = "${var.openstack_flavor}"
  key_pair = "${var.openstack_keypair}"
  security_groups = ["PreProdSG"]

  block_device {
    uuid                  = "${element(openstack_blockstorage_volume_v2.system.*.id, count.index)}"
    source_type           = "volume"
    destination_type      = "volume"
    boot_index            = 0
    delete_on_termination = false
  }
  block_device {
    uuid                  = "${element(openstack_blockstorage_volume_v2.volumes.*.id, count.index)}"
    source_type           = "volume"
    destination_type      = "volume"
    boot_index            = -1
    delete_on_termination = false
  }

  network {
    name = "${var.tenant_network}"
  }
}

resource "openstack_compute_floatingip_v2" "floatIP" {
  count = "${var.num}"
  pool = "Non-Prod"
}

resource "openstack_compute_floatingip_associate_v2" "floatIP" {
  count = "${var.num}"
  floating_ip = "${element(openstack_compute_floatingip_v2.floatIP.*.address, count.index)}"
  instance_id = "${element(openstack_compute_instance_v2.push.*.id, count.index)}"
}

output "floatingAddress" {
  value = "${openstack_compute_floatingip_associate_v2.floatIP.*.floating_ip}"
}

Debug Output

Crash Output

Expected Behavior

Floating IP should be assigned to instances in sequential manner. Example: Test01 instance should assign Floating IP with 10.X.X.21 Test02 instance should assign Floating IP with 10.X.X.22 Test03 instance should assign Floating IP with 10.X.X.23 Test04 instance should assign Floating IP with 10.X.X.24 Test05 instance should assign Floating IP with 10.X.X.25

Actual Behavior

Floating IP getting assigned/associate randomly.

Test01 instance assigned Floating IP with 10.X.X.22 Test02 instance assigned Floating IP with 10.X.X.25 Test03 instance assigned Floating IP with 10.X.X.23 Test04 instance assigned Floating IP with 10.X.X.21 Test05 instance assigned Floating IP with 10.X.X.24

Steps to Reproduce

terraform init
terraform apply

Additional Context

References

https://github.com/hashicorp/terraform/issues/10022

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 21 (10 by maintainers)

Most upvoted comments

@rp85 I believe this issue is not related to the terraform openstack provider, but to your environment. Terraform ensures that instances are correctly provisioned and have an ACTIVE state. However, in your case, instances have ERROR state. Please try to get in touch with the Openstack environment administrators and clarify what exactly did cause the issue.

kayrus on Jan 21, 2019

It appears this is an issue with Terraform core. Since sorted_fips is made from a computed value, it’s triggering the recreate of openstack_compute_floatingip_associate_v2.

You can verify this does not happen when you create a standard variable that statically defines the IPs:

variable "floating_ips" {
  type    = "list"
  default = [
    "192.168.1.100",
    "192.168.1.101"
  ]
}

...

resource "openstack_compute_floatingip_associate_v2" "floatIP" {
  count       = "${var.num}"
  instance_id = "${openstack_compute_instance_v2.push.*.id[count.index]}"
  floating_ip = "${var.floating_ips[count.index]}"
}

Another option, which is more of a hack is to do:

resource "openstack_compute_floatingip_associate_v2" "floatIP" {
  count       = "${var.num}"
  instance_id = "${openstack_compute_instance_v2.push.*.id[count.index]}"
  floating_ip = "${local.sorted_fips[count.index]}"

  lifecycle {
    ignore_changes = ["floating_ip"]
  }
}

Looping back to my original suggestions: defining a static list of floating IPs is the most straightforward way to go here. It’s possible that Terraform v0.12 will have better support for not causing these kinds of triggers, but as it stands right now, I’m quite sure this is a known issue (I can’t find any relevant issues at https://github.com/hashicorp/terraform at the moment, but I know I have seen them before. Searching for “forces new resource” and “computed” should turn up some relevant results).

jtopjian on Jan 17, 2019

You can just as easily make a list of available floating IPs using a standard list variable and use the same count / element combination.

For example:

resource "openstack_networking_floatingip_v2" "fip" {
  count = "${var.num}"
  ...
}

locals {
  sorted_fips = "${sort(openstack_networking_floatingip_v2.fip.*.address)}"
}

resource "openstack_compute_instance_v2" "test" {
  count       = "${var.num}"
  ...
}

resource "openstack_compute_floatingip_associate_v2" "test" {
  count       = "${var.num}"
  instance_id = "${element(openstack_compute_instance_v2.test.*.id, count.index)}"
  floating_ip = "${local.sorted_fips[count.index]}"
}

This use-case does not necessitate the need for a non-standard data source such as openstack_networking_floatingip_ids_v2. We should be mindful of suggesting such things.

After thinking about the situation in general, the only way this is going to work is if the user can be absolutely confident that there is a continuous range of floating IPs available to retrieve. Neutron, by default, will allocate a random floating IP from the available pool. Additionally, if the floating ip pool is shared by several tenants (which it usually is), then other tenants may cause the sequence to have holes in it.

In general, the best practice here would be to accept that the data will be out of order. I feel like there is going to be a lot of effort spent trying to enforce a sequence.

jtopjian on Jan 15, 2019