feat: time_sleep is missing

[antdking]

Recently helped out someone who needed to wait for a period of time before starting a create operation.

Whilst this isn't ideal, it's currently the only way due to a mixture of pulumi + other tools. In their case, it's not having access to the IP address of a k8s service due to needing to skip the await checks that normally wait for the IP address to exist.

In terraform, they used time_sleep, however it's absent from this wrapper.

In the resource definition, you note that Pulumi has other ways, however I'm not familiar with a general solution outside of falling back to using the Command provider where the create operation needs holding up.

Slack thread where this is mentioned

[tmeckel]

@antdking Pulumi uses programming languages to describe deployments. So you would use some kind of sleep method that is provided by the programming language you are using.

For example, in NodeJS you can use setTimeout(). In C# (dotnet) Thread.Sleep.

The only language that might benefit from the time_sleep method would be YAML. But I'd recommend using a real programming language if there is a demand for waiting for a specific time.

[antdking]

Whilst you can do those within Output.apply, there isn't an easy way to limit to just create or delete operations

[tmeckel]

@antdking Ahh ... I might see the issue: the provider executes actions regardless of waiting statements inside the program because the provider is executed as a standalone process aside the Pulumi program.

I see the benefit while creating resources but how'd you wait for a delete? The time_sleep method supports depends_on which will pause the provider for a certain time after a resource has been created.

But when a resource is deleted, the dependent resources are deleted first, so the time_sleep resource is destroyed before the corresponding resource is destroyed, and eventually there's no wait at all after the actual resource is deleted.

Well you could add a time_sleep with any dependencies at all. But that's, at least, awkward.

[antdking]

The upstream docs have an example of deletion delays, where by time_sleep depending on a resource will cause that resource to delay. It looks awkward, I don't see it being used much.

I think the main usecase is for creation delays. There's since been someone else say they use Command.local to cause a delay due to a bug in the aws TF provider for Transit Gateway.

[antdking]

The docs should definitely include a warning that say waiting a period of time isn't a good solution for most cases, and they should try to use other tools to wait for the expected state in production environments; such as kubectl --watch or a poll loop with their respective sdk within an Output.apply block

[GeoffMillerAZ]

+1 to mapping the resource, even though there may be better options.

The fact is, this resource is used a LOT in terraform. We should expect to see this resource in abundance when converting Terraform code and state to Pulumi.

There is new tooling for aiding in adopting Pulumi from Terraform via code and state conversion. The value of these tools is to make a quick and painless adoption experience. Providing a mapped equivalent will improve this effort and speed up adoption efforts from state and code conversion perspectives—one less thing to worry about. Although this is not critical, It would be helpful.

[tmeckel]

@antdking @GeoffMillerAZ preparing a new release including the time_sleep resource.

[tmeckel]

@antdking @GeoffMillerAZ @maiku1008 Folks the new release has just been published.