Jumping off topic with you for a moment: It's something that's been brought up with the Bicep folks for several years now, but I see a couple of problems with taking an ARM dependency straight off an auto-generated resource with little else in the way of overhead management:

Some resources (vnets are an excellent example) don't support patch updates and only allow full-resource replacements
Several resources (RBAC comes to mind, but there are a great many of them reported on this thread) will mark as completed in deployments even though they haven't actually propagated to all the places they're intended to be used). I reported Azure Data Explorer as another one that reports complete for ARM purposes, but goes into some maintenance mode and isn't eligible for further ARM updates until that completes.

In other words, ARM (and Bicep) doesn't yet have a retry mechanism and the complete deployment state cannot necessarily be trusted. The ARM management SDKs (Azure.ResourceManager.*) don't accommodate this as they're auto-generated and leave it to the consumer to deal with. I'd recommend as part of factoring into longer-term plans either getting the Azure teams to fix ARM completion reporting on their end (ideal), waiting to see if Bicep adds something to address this or add something into Aspire itself to accommodate this. Personally, I have a bunch of delay PowerShell deployment scripts in my own Bicep project that intentionally add waiting periods with a check loop to accommodate this.

Do you have a list anywhere of known "unknowns" in terms of design areas you'd welcome suggestions of handling or are you more looking for external solutions to crop up to identify perceived shortcomings like Achieve.Aspire.AzureProvisioning? I know storing declarative secrets in Key Vault is one I raised before, but I don't know that I've seen it called out in a specific list anywhere.

On topic: I'm not super familiar with dev tunnels, but please, please, please avoid the issue that plagued local Service Fabric development - namely that because the local SF cluster ran under a different user account, it wasn't able to utilize Azure.Identity for anything but certificate-based authentication to Entra SPs which was a real pain. It's nice to be able to lean on chained token credentials and specify a UAI client ID and a VS credential fallback and have development experience otherwise Just Work without having different authentication in different deployment environments.

Add Azure Event Grid Aspire Integration #788

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions