Allow Assign Existing Float IP to New Droplet about terraform-provider-digitalocean HOT 11 CLOSED

I think this is a glaring omission in this provider. Setting up DNS ahead of time to point to a pregenerated floating IP address is a must for rapid deployment of servers.

from terraform-provider-digitalocean.

Running into the same issue. Correct me if I am wrong but, due to this, we currently have no means to retain a floating_ip upon the destruction of its currently allocated droplet?

from terraform-provider-digitalocean.

This should have the enhancements tag. I can't believe this has not been addressed since the original ticket in October 2016

from terraform-provider-digitalocean.

Hi,
This is an issue for me as well. Being able to point a new host to an existing floating IP would help get round an issue I raised in the main Terraform Git as well.

Regards,
Andy

from terraform-provider-digitalocean.

Is this going to be addressed at some point by any chance? I don't have time to pick it up right now but need it for a project at some point soon.

from terraform-provider-digitalocean.

@BradErz I don't think so. The original ticket was created on 13 Oct 2016: hashicorp/terraform#9353

from terraform-provider-digitalocean.

@eddiezane can you take a look to this issue?

from terraform-provider-digitalocean.

Hi all,

I am trying to better understand the issue here to determine if the problem is the lack of documentation or if there is a need for an enhancement as well.

In this minimal example, I've created two Droplets (foo and bar) and one floating IP attached to the first Droplet:

resource "digitalocean_droplet" "foo" {
     image  = "ubuntu-16-04-x64"
     name   = "terrform-droplet-foo"
     region = "nyc3"
     size   = "s-1vcpu-1gb"
}

resource "digitalocean_droplet" "bar" {
     image  = "ubuntu-16-04-x64"
     name   = "terrform-droplet-bar"
     region = "nyc3"
     size   = "s-1vcpu-1gb"
}

resource "digitalocean_floating_ip" "foobar" {
  droplet_id = "${digitalocean_droplet.foo.id}"
  region     = "nyc3"
}

If I update the config to the below, the existing floating IP is moved from Droplet foo to Droplet bar.

resource "digitalocean_droplet" "foo" {
     image  = "ubuntu-16-04-x64"
     name   = "terrform-droplet-foo"
     region = "nyc3"
     size   = "s-1vcpu-1gb"
}

resource "digitalocean_droplet" "bar" {
     image  = "ubuntu-16-04-x64"
     name   = "terrform-droplet-bar"
     region = "nyc3"
     size   = "s-1vcpu-1gb"
}

resource "digitalocean_floating_ip" "foobar" {
  droplet_id = "${digitalocean_droplet.bar.id}"
  region     = "nyc3"
}

Updating the config again to remove the droplet_id attribute from the floating IP, I am successfully able to unassign the floating IP from either Droplet without destroying the floating IP.

resource "digitalocean_droplet" "foo" {
     image  = "ubuntu-16-04-x64"
     name   = "terrform-droplet-foo"
     region = "nyc3"
     size   = "s-1vcpu-1gb"
}

resource "digitalocean_droplet" "bar" {
     image  = "ubuntu-16-04-x64"
     name   = "terrform-droplet-bar"
     region = "nyc3"
     size   = "s-1vcpu-1gb"
}

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

Is there a use case I am missing? It seems like a Floating IP datasource would probably be useful, but that doesn't seem to be what people are asking for here.

Thanks!

from terraform-provider-digitalocean.

@andrewsomething the issue to assign during float ip on create a new droplet.

resource "digitalocean_droplet" "bar" {
     image  = "ubuntu-16-04-x64"
     name   = "terrform-droplet-bar"
     region = "nyc3"
     size   = "s-1vcpu-1gb"

     float_ips = ["digitalocean_floating_ip.foobar.id"]
}

It seems floating ip now support assign droplet. the issue was created 2 years ago hashicorp/terraform#9353.

from terraform-provider-digitalocean.

Agreed - it's around how to assign an existing floating IP to a new server. Given the time it takes to set up DNS entries, I have created the DNS entries manually, then created the floating IP manually. That's so that they are not accidentally destroyed in any Terraform destroy process, as destroy doesn't allow you to exclude specific items when rebuilding the environment.

I then create the servers via Terraform as usual. But to get the non-terraform floating IP to point to the new Terraformed server, I have to hop out of Terraform and use a custom node script I wrote, which uses the DigitalOcean API.

Not a huge headache in terms of technical requirements, but just makes it a very disjointed process.

Hope that helps,
Andy

from terraform-provider-digitalocean.

I don't have time right now to write tests for it, but I believe I've implemented a new resource that meets this need.

See my fork: oliviabarrick@e739f5a

    Allows assigning an already existing floating ip to a droplet via a new resource (fixes #8).

    Adds a `digitalocean_floating_ip_assignment` resource so that a floating IP that
    already exists can be assigned to a droplet.
    
    I've also added the `ignore_droplet_id` flag to the `digitalocean_floating_ip` so that
    the existing floating IP resource can be used to create these IPs.
    
    A new resource was used to prevent circular dependencies.

Example usage:

provider "digitalocean" {
  token = "${var.digitalocean_token}"
}

resource "digitalocean_floating_ip" "ip" {
  region = "tor1"
  ignore_droplet_id = true
}

resource "digitalocean_floating_ip_assignment" "ip" {
  ip_address = "${digitalocean_floating_ip.ip.ip_address}"
  droplet_id = "${element(digitalocean_droplet.my_droplet.*.id, 0)}"
}

resource "digitalocean_droplet" "my_droplet" {
  count = 3

  name = "example-${count.index}"

  image = "debian-9-x64"
  region = "tor1"
  size = "s-1vcpu-1gb"

  user_data = <<EOL
#cloud-config
runcmd:
- [ "ping", "${digitalocean_floating_ip.ip.ip_address}" ]
EOL
}

from terraform-provider-digitalocean.