Flag to force serial provisioning of a resource when using count.

[dsalazar-carecloud]

trafficstars

Love the count property but sometimes I still need the resulting instances, talking aws here, to come up and provision in a serial fashion. Is there a way to force this? Currently I'm having to copy the same resource and put a depends_on to force the 1 x 1 behavior that I require. Any ideas would be greatly appreciated. On that note TForm Rocks!

[mitchellh]

Thanks! I'll tag this as an enhancement. A feature request like this may already exist but until we find it will just tag it.

[dsalazar-carecloud]

Great appreciate it! 👍

[huntcsg]

👍

[ansoni]

Sad that it doesn't have this already. This is important for APIs that are not thread-safe. AWS's lambda permissions API is one of those - https://www.terraform.io/docs/providers/aws/r/lambda_permission.html

using count results in lost permission updates. This enhancement would solve that.

[apparentlymart]

In the case of specific resources that, due to limitations of the underlying API, require limited or no concurrency, we can address that directly within the resource implementation, similar to what was discussed in #14550. So if you know of cases like these it'd be helpful to open top-level issues for each so we can attack them separately.

That's not to say that serializing counts isn't a reasonable idea in the long run, just that we can generally fix these resource-specific annoyances on a case-by-case basis much more easily due to the fact that the change is isolated to only one small part of Terraform.

[TheBlackMini]

Hi, just wondering if this is being worked on or has been resolved? I've hit a problem which is not thread-safe (powershell in the null_resource).

[zhujinhe]

The backend server returned time out while I was uploading several images using count. Force serial would be a nice way to smooth the traffic curve in this scenario.

[andrea-berling]

I would also be interested in this. I'm trying to install 3 Helm releases using the helm provider, and installing them concurrently results in conflicting manifests for them. The correct manifests would be generated if the creation of these resources were serialised

[slayer01]

Is there any news on this topic? I ran in a problem where this could help. In my case I´d like to deploy VMs for AVD in serial, so in the case of an updated image the VMs will be renewed one by one, a rolling update so to say.

Would really appreciate this feature. Thanks.

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions.

Adding this comment very late to help viewers take the right actions to get this seen. Thanks!

[ClusterDaemon]

I have a case for this when using helm_template data source output (processed as a collection of manifests), fed to the kuberentes_manifest resource via for_each. Helm template is prone to sometimes output List kinds, which is a client-side abstraction that cannot be submitted to K8s directly. Lists are used when arbitrary ordering of resources is required in special cases where apply of one resource will fail if another doesn't exist (which is rare enough, but can be seen in the AWS LB controller chart).

helm install handles this via serializing the List item apply process, whereas Terraform has no such concept of doing so within a collection. Since one typically cannot know when these lists will appear or how long they are until a given chart is templated, this must be specially handled per-chart using separate kubernetes_manifest resources for each anticipated list item with depends_on performed serially rather than via a more autonomous collection.

While this workaround "functions", it's not pretty.