provider/digitalocean: ssh_keys doesn't update on digitalocean_droplet about terraform-provider-digitalocean HOT 8 CLOSED

@gdubicki yes, of course.

resource "digitalocean_droplet" "example" {
  ssh_keys = [
    "${digitalocean_ssh_key.default.fingerprint}",
    "${digitalocean_ssh_key.example.fingerprint}",
  ]

  connection {
    user    = "root"
    type    = "ssh"
    timeout = "60s"
    agent   = true
  }
}

Supplying the connection settings resolved the issue of not updating SSH keys added/changed for me. Previously I only had ssh_keys set. We're using it like this for almost half a year on production systems with no problems.

from terraform-provider-digitalocean.

This comment was originally opened by @cabbiepete as hashicorp/terraform#2733 (comment). It was migrated here as part of the provider split. The original comment is below.

This is more of a DO thing than a terraform thing. DO only provisions ssh keys when you create droplets it never updates them post this. You can use a provisioner such as remote exec, chef, puppet to ensure the full list of keys is there.

from terraform-provider-digitalocean.

This comment was originally opened by @apparentlymart as hashicorp/terraform#2733 (comment). It was migrated here as part of the provider split. The original comment is below.

Based @cabbiepete's comment, it sounds like the bug here is that we should have ForceNew set on that attribute so that Terraform knows that it has to create a replacement droplet in order to implement an SSH key change.

from terraform-provider-digitalocean.

This comment was originally opened by @cabbiepete as hashicorp/terraform#2733 (comment). It was migrated here as part of the provider split. The original comment is below.

@apparentlymart I'd expect that to be an optional setting and default to not. There are other ways to get the new/updated ssh key to the server in less destructive ways which is a better default for anyone that does not quite know all the details of terraform and that particular provider.

from terraform-provider-digitalocean.

This comment was originally opened by @apparentlymart as hashicorp/terraform#2733 (comment). It was migrated here as part of the provider split. The original comment is below.

@cabbiepete is there something that Terraform could do automatically/programmatically when it detects a diff on this attribute? ForceNew is how Terraform models things that can only be set at creation time and can't be updated later, so that's the right thing to do unless there's something less destructive that Terraform could do instead, to apply an update here.

Your earlier comment suggested that logging in to the machine and manually tweaking the keys was the only path. If so, this is a similar situation to Amazon EC2, where the corresponding attribute (key_pair) is marked as ForceNew as I described.

from terraform-provider-digitalocean.

This comment was originally opened by @danielsreichenbach as hashicorp/terraform#2733 (comment). It was migrated here as part of the provider split. The original comment is below.

Adding my two cents here. I just did this on an existing droplet, where I needed to extend set of SSH keys deployed.

This is actually working, if you supply a connection object in the droplet configuration, and then add further entries to the SSH configuration.

from terraform-provider-digitalocean.

What you mean by "supplying a connection object", @danielsreichenbach ? Can you share the code that is working for you?

from terraform-provider-digitalocean.

Closing this issue. Retroactively adding and removing SSH keys is not something the API allows us to do. I would recommend using a configuration management tool such as Ansible, Salt, or Puppet for managing identity past the initial provisioning step. The connection work around provided appears to work so that is another viable solution.

from terraform-provider-digitalocean.