triton_machine does not support lifecycle block

[Bang-Kwangmin]

Terraform Version

Terraform v0.10.5

Terraform Configuration Files

resource "triton_machine" "instance" { lifecycle { create_before_destroy = true } count = "${var.group_scale}" name = "${lookup(var.region_prefixes, var.triton_datacenter)}${var.service_name}${format("%03d", count.index + var.start_index)}" package = "${var.instance_container_package}" image = "${data.triton_image.base.id}" firewall_enabled = false networks = ["${data.triton_network.private.id}", "${data.triton_network.public.id}"] }

Debug Output

Error applying plan:

10 error(s) occurred:

• triton_machine.instance[2]: 1 error(s) occurred:

• triton_machine.instance.2: Error executing Create request: ValidationFailed: Invalid VM parameters: Invalid machine name

• triton_machine.instance[3]: 1 error(s) occurred:

Expected Behavior

I'd like to rolling upgrade all instances.

Actual Behavior

Terraform can not apply plan

[chorrell]

I think what's causing this is that CloudAPI requires machine names to be unique which prevents a new machine with the same name from being created before the old one is destroyed.

[Bang-Kwangmin]

On triton, I'm preparing Packer + Terraform for image based deployment. If Terraform can not support lifecycle block because Triton instance names have to be unique, I can not deploy new image in order, right ? is there any good idea for rolling deployment via terraform ?

[siepkes]

@Bang-Kwangmin You could give machines unique (random) names and then use Triton CNS to divert traffic.

[jwreagor]

@Bang-Kwangmin machine names must be unique on Triton. This is something Terraform cannot change.

As for create_before_destroy, it was not meant for rolling deployments but for ensuring infrastructure dependencies exist across deletions (and it has known issues doing this). Examples are making sure a DNS record or load balancer exists before destroying an old one. While this does sound like rolling deployments, this feature was not created for that. You'll need to consider other options for your architecture on Triton.

@siepkes is correct with his suggestion to look into Triton's CNS feature. It might be an option for what you are trying to achieve. There is a new CNS stanza under triton_machine which allows you to attach multiple instances to a single DNS record using the same CNS service names. Like everything there are caveats but know that you have options for architecting rolling deployments on Triton using the right tools.

[jwreagor]

I'm going to close this if there are no other objections.