DigitalOcean floating IP destroyed on droplet refresh

[franklinhu]

This is related to: #2011

Following the example in the docs [0], I'm seeing behavior where terraform destroys a floating IP if the upstream droplet is changed. This seems pretty undesirable since floating IPs are supposed to be static across infrastructure changes, so it seems like the relationship between droplets and floating IPs should be inverted.

[0] https://terraform.io/docs/providers/do/r/floating_ip.html

[stack72]

@franklinhu so the behaviour is as follows:

1. Floating IP is created and assigned to a droplet
2. Droplet is destroyed
3. Floating IP is then destroyed by Terraform

Is this correct? This seems correct to me. Terraform is trying to basically cleanup after itself. If the droplet is no longer needed then Terraform is trying to cleanup the no longer needed Floating IP. Is this not the case you were looking for?

[franklinhu]

For my particular use case, I want to use a floating IP that never changes since I've pointed DNS at it. Changes to the DNS record have unknown propagation time given client caching, so they may cause for my app to be unreachable.
For droplets, I've enable create_before_destroy and want to repoint the floating IP to the new one before destroying the old one. This allows for graceful upgrades/deploys since the IP will always have a backing droplet.

It feels like it'd be nice if the droplet configuration allowed you to specify a floating IP to use, but not sure if that's feasible.

[stack72]

ok i see what you mean. So right now you would want to do something like:

resource "digitalocean_droplet" "foobar" {
    name = "baz"
    size = "1gb"
    image = "centos-5-8-x32"
    region = "sgp1"
    ipv6 = true
    private_networking = true
    floating_ip = "${digitalocean_floating_ip.foobar.ip_address}"
}

resource "digitalocean_floating_ip" "foobar" {
    region = "sgp1"
}

[franklinhu]

Yep!

[ColinHebert]

Not sure it's worth inverting the relationship. The main problem is that a floating_ip shouldn't be re-created when the droplet_id changes (which is the entire point of having a floating ip in the first place).

It should be a oneline change ( https://github.com/hashicorp/terraform/blob/master/builtin/providers/digitalocean/resource_digitalocean_floating_ip.go#L35 )

[chulkilee]

DigitalOcean API does not let you specify ip address when creating a droplet. Instead, there is another API for assigning floating ip to droplet: https://developers.digitalocean.com/documentation/v2/#assign-a-floating-ip-to-a-droplet.

I think DO API should allow floating_ip when creating a droplet... (I posted the idea on their uservoice site) but until that terraform should take care of it.

I'm not sure what is the "terraform" way to handle this. Does terraform have convention that each resource should map to a provider's resource?

• Option 1: add floating_ip_id on digitalocean_droplet and let digitalocean_droplet resource call additional API to assign floating api after creating the droplet (as @stack72 showed)
• Option 2: reuse existing digitalocean_floaing_ip resource if droplet_id is changed (provider/digitalocean: Do not force the creation of a new IP when the droplet_id changes #4476 by @ColinHebert)
• Option 3: add "dummy" association resource to handle relationship between floating ip and droplet, and let it behave like option 2.

[ColinHebert]

The exact same system exists in AWS with elastic IPs. EIPs are simply a different resource (same for floating IPs) in the provider, which is convenient because they are actually a different element in both AWS and Digital Ocean.
They do not have to be attached to an instance/droplet to exist and the association can be done/undone without the instance/droplet being destroyed.

Option 1 disregards entirely the fact that the floating IP (or elastic IP) is an independent resource
Option 3 is only useful when the associations are many to many or one to many (in some cases), in this case it's a one to one, so it isn't worth having an association resource.

[stack72]

Hi all

Can someone tell me if this is an issue?

Paul

[stack72]

Closing for now - if this is still an issue then we can reopen

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