DigitalOcean backups enabled despite config

[mgood]

I've been trying Terraform for managing DigitialOcean droplets, but in spite of my configuration, all droplets created have been enabled for backups.

$ terraform --version
Terraform v0.3.6

This was my starting config which has no setting for "backups":

resource "digitalocean_droplet" "docker" {
    image = "docker"
    name = "docker-${count.index}"
    region = "nyc3"
    size = "512mb"
    private_networking = true
    ssh_keys = [1234]
}

I expected backups to be disabled by default, however when the droplet was created, they were enabled.

I have also tried explicitly setting the backups key as a boolean:

backups = false

and a string:

backups = "false"

In all cases, backups were still enabled.

When creating a droplet through other tools such as Docker Machine, backups are disabled by default, so the issue does not appear to be on DigitalOcean's end. It could be a problem in Terraform, or possibly the DigitalOcean driver it was built with.

[daneuriona]

I've verified that the api for digital ocean behaves appropriately (backups = false results in no backups). Can't seem to find where things are going south in the source code.

With backups enabled most terraform runs will fail because the assets are unavailable during a backup. It becomes totally unusable once you have a handful of droplets being managed.

[publysher]

I can confirm that the API for DigitalOcean does not behave appropriately. The DO API allows you to specify droplet creation parameters using either a JSON POST body, or as URL request parameters. When using "backups=false" in the URL request parameters, DO still enables backups on the droplet.

If you really want, compare the following to cURL calls, and see how the latter enables backups:

curl -X POST -H 'Content-Type: application/json' -H 'Authorization: Bearer YOUR_TOKEN' -d '{"name":"example.com","region":"nyc3","size":"512mb","image":"ubuntu-14-04-x64","ssh_keys":null,"backups":false,"ipv6":true,"user_data":null,"private_networking":null}' "https://api.digitalocean.com/v2/droplets" 

versus

curl -X POST -H 'Content-Type: application/json' -H 'Authorization: Bearer YOUR_TOKEN' "https://api.digitalocean.com/v2/droplets?name=example.com&region=ams3&size=512mb&image=ubuntu-14-04-x64&backups=false&ipv6=true&user_data=&private_networking=" 

TF uses github.com/pearkes/digitalocean, which uses the request parameter convention.

Possible solutions to this problem:

• Use a different client library
• Hope that DO fixes this problem

[mgood]

Thanks, that explains why the behavior was different from other apps using the API. (I had cloned terraform to look into it, but my dev builds are panicking for some reason.)

I can open a support ticket on DO to make sure they're aware of the issue.

[mgood]

I've reported this to DO, so I'll follow up here once I hear back.

Although pearkes' library is doing the right thing, DigitalOcean does have their own "official" Go client now, which might be worth checking out:

https://github.com/digitalocean/godo

[mgood]

On further investigation, it seems that the DO API simply treats boolean flags in the query parameters as "empty" or "non-empty". When @pearkes library passes the string "false", it's being treated as "non-empty" and therefore "true".

I tried this with the other boolean flags like "ipv6" and "private_networking" as well, and found the same behavior.

I'm not sure if this behavior changed on the DO backend at some point, or if it was just an oversight.

@pearkes what do you think, does it make sense to change the library to pass empty strings for "false" values?

On the DO support ticket, I've asked them to at least clarify the intended boolean behavior in the docs.

[pearkes]

Yea, at one point this worked I'm quite sure. DO has changed their API in the past so I wouldn't be totally surprised.

Thanks for tracking this down. I think we should omit the flag altogether for false values.

@mitchellh Is going to take care of the fix for this.

[mgood]

Sounds good, thanks

[publysher]

I just got a reply from DO that they are looking into this issue, so @mitchellh might hold back changing the client.

[phillbaker]

I'm an engineer at DO - we're taking a look at this. If you find anything else, feel free to cc me. Thanks!

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