Terraform: provider/openstack: remote-exec fails with openstack_compute_floatingip_associate_v2

[dvianello]

Terraform Version

Terraform v0.9.2

Affected Resource(s)

Please list the resources as a list, for example:

• openstack_compute_instance_v2
• openstack_networking_floatingip_v2
• openstack_compute_floatingip_associate_v2

Terraform Configuration Files

resource "openstack_compute_instance_v2" "instance" {
  name             = "${var.name}-instance-${count.index + 1}"
  image_id         = "${var.disk_image}"
  flavor_name      = "${var.machine_type}"
  key_pair         = "${var.key_name}"

  network {
    name           = "${var.net}"
    access_network = true
  }

  provisioner "remote-exec" {
    connection {
        user       = "core"
        #private_key= "${file("${var.key_path}")}"
  }
    inline = [
      "docker run -d ${var.docker_ports} ${var.docker_repository}",
      "echo terraform executed > /tmp/foo"
    ]
  }
  security_groups = [
    "${openstack_compute_secgroup_v2.allow-ssh.name}",
  ]
}

resource "openstack_networking_floatingip_v2" "floatingip" {
  pool = "${var.floatingip_pool}"
}

resource "openstack_compute_floatingip_associate_v2" "instance_floating" {
  floating_ip = "${openstack_networking_floatingip_v2.floatingip.address}"
  instance_id = "${openstack_compute_instance_v2.instance.id}"
}

Expected Behavior

TF spins up the VM, crates & associates the floating IP, execute the remote-exec

Actual Behavior

Floating ip is created but not attached, remote-exec times out and provisioning fails.

Steps to Reproduce

1. terraform apply

[jtopjian]

@dvianello Thanks for this.

This is actually expected behavior and one of the downsides of deprecating the built-in floating IP support for instances. The reason why the provisioner isn't working in the instance is because it is triggered before the floating IP is associated.

The two recommended ways of running provisioners now are:

1. Do it in the openstack_compute_floatingip_associate_v2 resource
2. Create a null_resource to house the provisioning.

IMO, the latter is the best method. null_resources are common provisioning mechanisms to help simplify provisioning.

In either of the above cases, you'll want to embed a connect block like so:

resource "null_resource" "provision" {
  depends_on = ["openstack_compute_floatingip_associate_v2.instance_floating"]
  connection {
    user = "username"
    private_key = "${file("/path/to/id_rsa")}"
    host = "${openstack_network_floatingip_v2.floatingip.address}"
  }

  provisioner "remote-exec"
    ...
  }
}

I do realize this creates some extra work in configurations, but I believe the tradeoff is better flexibility with regard to using Terraform with various OpenStack clouds.

Let me know if you have any questions. As well, if you have a suggestion on how to better handle a scenario like this, absolutely let me know -- I could be totally wrong in these situations :)

[dvianello]

Ah-ah! I knew I must have been missing something - null_resource in this case & its usage in provisioning!

Totally agree with you this is the way forward - I can't see where this approach might fail in our current deployments, so...sorry about the kind of non-existent issue!

[jtopjian]

@dvianello No problem at all! :)

[markelog]

Maybe it would be a good idea to document it?

[hashibot[bot]]

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.