regression: droplet_agent is not honored for digitalocean_droplet resource

[artis3n]

Bug Report

---

Describe the bug

The Droplet agent seems to be installed regardless of whether or not the droplet_agent argument is set to true or false.

Affected Resource(s)

• digitalocean_droplet

Expected Behavior

Setting droplet_agent to false should not install the droplet agent at all on the droplet. I expect to SSH into a fresh VM and get a Unit droplet-agents.service could not be found error when I run systemctl status droplet-agent.

Actual Behavior

The Droplet Agent is installed even if the droplet_agent argument is set to false.

Steps to Reproduce

1. Copy the below Terraform
2. Run terraform apply
3. SSH to the server
4. Run systemctl status droplet-agent
5. Observe the agent is still installed and is active

Terraform Configuration Files

resource "digitalocean_droplet" "test" {
  image  = "ubuntu-22-04-x64"
  name   = "example"
  region = "nyc3"
  size   = "s-1vcpu-1gb-amd"
  droplet_agent = false

  # For the purposes of this example code, just generating a random ssh key.
  # Use your own fingerprint to SSH in and verify the droplet agent service is active
  ssh_keys = [digitalocean_ssh_key.test.fingerprint]
}

resource "digitalocean_ssh_key" "test" {
  name       = "random"
  public_key = trimspace(tls_private_key.test.public_key_openssh)
}

resource "tls_private_key" "test" {
  algorithm   = "ED25519"
  ecdsa_curve = "P256"
}

output "test_ip" {
  value = digitalocean_droplet.test.ipv4_address
}

Expected behavior

terraform -v

Terraform v1.2.6
on linux_amd64
+ provider registry.terraform.io/digitalocean/digitalocean v2.21.0
+ provider registry.terraform.io/hashicorp/tls v3.4.0

Debug Output

Panic Output

Additional context

Important Factoids

References

• droplet_agent is not honored for digitalocean_droplet resource #779
• fix: handle optional boolean droplet_agent #785

[artis3n]

Confirmed that doctl compute droplet create ... --droplet-agent=false works, so the backend APIs are doing the correct things. Notably, I noticed that --droplet-agent false did not work. I assume that distinction is causing some issue between

terraform-provider-digitalocean/digitalocean/resource_digitalocean_droplet.go

Line 281 in 5acd3d3

opts.WithDropletAgent = boolPtr(attr.(bool))

where the parameter is converted into the doctl options and digitalocean/godo@f724a68 where it is passed into the godo client.

[andrewsomething]

Hi @artis3n,

I've been unable to reproduce this issue. I can successfully create a Droplet with droplet_agent = false that does not include the agent. Can you try again with debug output enabled, e.g. TF_LOG=debug terraform apply. This should show the actual HTTP requests being made. In my case, I saw:

---[ REQUEST ]---------------------------------------
POST /v2/droplets HTTP/1.1
Host: api.digitalocean.com
User-Agent: Terraform/1.2.6 godo/1.81.0
Content-Length: 216
Accept: application/json
Content-Type: application/json
Accept-Encoding: gzip

{
 "name": "test",
 "region": "nyc3",
 "size": "s-1vcpu-1gb-amd",
 "image": "ubuntu-22-04-x64",
 "ssh_keys": [
  107149
 ],
 "backups": false,
 "ipv6": false,
 "private_networking": false,
 "monitoring": false,
 "tags": [],
 "with_droplet_agent": false
}

[artis3n]

I can't either...
Ah!
The behavior I was seeing came from a base image via https://www.packer.io/plugins/builders/digitalocean#optional, then using Terraform to create a droplet from the snapshot generated by the packer build. Packer doesn't expose a way to disable the installation of the droplet agent. So the terraform flag was working but the snapshot already included the systemd service. Will throw an issue up over there and see if I have some time to make a PR!

[andrewsomething]

Thanks @artis3n Definetly seems like something we should support in Packer.

[artis3n]

FWIW #857 is validated with the plain base image.