pulumi-azure icon indicating copy to clipboard operation
pulumi-azure copied to clipboard

Azure custom hostname + new DNS records

Open barclayadam opened this issue 4 years ago • 4 comments

I'm using Pulumi to create an environment in Azure that has an Azure Web App, pointed at from Cloudflare.

Part of the Pulumi app I therefore have is to create a CustomHostnameBinding. Azure requires a verification DNS record to be live for this to work. The problem occurs when first setting up the environment because of DNS propagation.

I can wait a minute and then manually retry and it works, but is it possible to build-in this sort of delay to the application before it attempts to create the custom hostname?

barclayadam avatar Jan 10 '20 09:01 barclayadam

@stack72 would custom timeouts be an option here, or is this something that needs to be addressed in the underlying provider?

pgavlin avatar Jan 10 '20 16:01 pgavlin

By custom timeouts do you mean https://github.com/pulumi/pulumi/issues/2655?.

If the DNS has not been propagated the creation of the custom hostname would fail immediately and therefore fail the deployment

I may be off here but it feels like either:

a dependency wait change in that if something depends on a DNS record, the determination of when the DNS record has been "created" changes from "has been added to DNS" to "has propagated". Obviously that being difficult to determine.

or

ability to, as well as provide a timeout, indicate a "safe" failure that should not stop the process. In this case detect the problem is with creating a custom hostname and that the DNS record does not exist, therefore retry every x seconds for y times until timeout has been reached

barclayadam avatar Jan 10 '20 16:01 barclayadam

I've continued to hit this so curious to know if anything has changed in terms of options here?

It's DNS again but this time when creating a custom domain for an Azure Blob Storage account. I add the record to Cloudflare and then blob store is immediately created but cannot verify the domain. Re-running the stack works, but is not ideal in an automated / CI scenario

barclayadam avatar Nov 05 '20 13:11 barclayadam

3 years later, I'm running into the same issue, and wondering if you were able to find a way to avoid having to re-run the stack?

hognevevle avatar Nov 10 '23 07:11 hognevevle