CloudFront parameter to cause Terraform to wait until distribution is "Deployed"

[llarsson]

I would love to have a parameter to instruct the Terraform command to wait until the CloudFront distribution is in the Deployed state after making modifications. This would make it easier to add to e.g. scripts, where I need to wait until the change is (rather) reliably propagated before continuing with the next step.

[radeksimko]

I'm not sure how long does it usually take or should it take to deploy a CloudFront distribution change, but the convention we maintain in most resources is that we treat the creation/update/deletion as done when it's actually done, so what you're describing should in this case be a default behaviour rather than something you'd turn on/off via an attribute.

So far the only exception I know of (where we don't wait for the resource to finish an operation) is KMS - because the deletion has to be scheduled (7 days min) and is cancellable during that time period and Terraform can't obviously let the user wait 7 days 😃 .

[llarsson]

15 to 20 minutes, roughly.

Another attribute (on mobile, can't check), concerning deletion, already defaults to "just do it in the background, don't make me wait".

I don't care either way about what would be the default, I just want to be able to know when my change has been propagated. :)

Radek Simko notifications@github.com skrev: (10 september 2016 16:19:59 CEST)

I'm not sure how long does it usually take or should it take to deploy
a CloudFront distribution change, but the convention we maintain in
most resources is that we treat the creation/update/deletion as done
when it's actually done, so what you're describing should in this case
be a default behaviour rather than something you'd turn on/off via
an attribute.

So far the only exception I know of (where we don't wait for the
resource to finish an operation) is KMS - because the deletion has to
be scheduled (7 days min) and is cancellable during that time period
and Terraform can't obviously let the user wait 7 days 😃 .

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#8749 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[llarsson]

Actually, I was imprecise. It does not delete, it disables the distribution. That, however, means you have to remove it manually after terraform destroy, where after it will be cranky with you since you deleted a thing it thought it was managing, still.

Radek Simko notifications@github.com skrev: (10 september 2016 16:19:59 CEST)

I'm not sure how long does it usually take or should it take to deploy
a CloudFront distribution change, but the convention we maintain in
most resources is that we treat the creation/update/deletion as done
when it's actually done, so what you're describing should in this case
be a default behaviour rather than something you'd turn on/off via
an attribute.

So far the only exception I know of (where we don't wait for the
resource to finish an operation) is KMS - because the deletion has to
be scheduled (7 days min) and is cancellable during that time period
and Terraform can't obviously let the user wait 7 days 😃 .

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#8749 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[vancluever]

Guys,

Yeah - the creation takes about 20 minutes. This was making testing very hard to do, and was not actually important on any modification operation of the distribution except for deletion (example: a distribution can have its configuration modified or disabled while it's in a deploying state), so the deployed state waiter was moved to there.

The flag you guys are referring to is retain_on_delete, which defaults to false so that under normal circumstances, the distribution will delete okay, but if for some reason you can't wait the 20 minutes for the distribution to delete (ie: you are developing your infrastructure, or working on the resource itself in Terrafrom) it will just disable the distribution and skip deletion. The only real issue that I've seen where using retain_on_delete become an issue in Terraform is if there is an origin access identity set up with the distribution - if this is the case, TF will fail on deleting the origin access identity because it's still associated with the distribution.

A wait_for_deployed flag sounds fair, but given the length of time it takes for a change to be deployed, I don't think it should be defaulted to true, given that it can possibly add ~20 min to any Terraform run with an aws_cloudfront_distribution resource, regardless of what it's doing.

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