Add cloud_init argument to image creation

[stvnjacobs]

📝 Description

This adds the cloud_init flag to the image create step.

✔️ How to Test

There are no unit or integration tests included with this patch. I am putting it up for consideration before those are completed.

To test manually, and to get a working cloud-init image, an image can be created using an existing image which has the cloud-init capability.

$ linode-cli images list --text --is_public true --format id,capabilities | awk '/cloud-init/ { print $1 }'
linode/debian11
linode/ubuntu20.04
linode/ubuntu22.04
linode/ubuntu23.10

📷 Preview

locals { timestamp = regex_replace(timestamp(), "[- TZ:]", "") }

source "linode" "demo" {
  image          = "linode/debian11"
  image_label    = "demo-debian11"
  instance_label = "pkr-demo-debian11-${local.timestamp}"
  instance_type  = "g6-nanode-1"
  region         = "us-iad"
  ssh_username   = "root"
  cloud_init     = true
}

🤔 Additional Thoughts

Config structure

I was uncertain on the best way to format the config. I am sure I am over thinking it, but what good does that do if I don't share where my head is at.

POST /v4/images: When an image is created, cloud-init is a boolean.

GET /v4/images/{imageId}: When an image is viewed, cloud-init is one of an array of capabilities.

I was unsure whether to structure the config so it matches the create arguments:

source "linode" "demo" {
  image      = "linode/debian11"
  # ...
  cloud_init = true
}

Or to model it like the image resource it creates.

source "linode" "demo" {
  image        = "linode/debian11"
  # ...
  capabilities = ["cloud-init"]
}

In these situations I typically refer to official hashicorp cloud provider plugins, but I couldn't really find anything comparable.

Unfamiliar with codebase

I admit to being a bit rusty around these parts. the hcl2spec.go was new to me, and in config.go is wasn't sure if required:"false" was really needed. I am just committing this as a proof of what worked for me, not what is fully correct.

[lgarber-akamai]

@stvnjacobs I think the first implementation you mentioned (cloud_init = true) is ideal since Packer isn't stateful 👍

[lgarber-akamai]

LGTM! This PR doesn't add proper E2E testing for cloud_init given #185 hasn't been merged quite yet but the change is simple enough that unit tests should be sufficient

[lgarber-akamai]

Failing tests are unrelated to this PR 🙂