Bicep Community Call - January '23

[stephaniezyen]

We are hosting our first Bicep community call of the new year on Thursday, January 26th at 9AM PST!

Use this issue to address topics you would like to discuss, questions you have for our team, further demos you would like to see, and any high or low points you would like to share. This is an open space for our users to discuss any topics they would like to talk about with our team.

You can list topics of discussion in this thread OR you can ask questions during the Q&A portion of the call.

Please sign up here to get an invite to the call. See you there!

[WhitWaldo]

Especially if there's some time at the end of the call, I'd love to hear any planned timeline for the following (no particular order):

• Feature: Augment map function to also include index of item #9462
• Custom type imports #9311
• Where things stand on getting ARM providers to honor "actually finished deploying" contract so dependency deployments don't fail because it's not actually available or providing built-in functionality to accommodate as a fallback (Add "wait" and "retry" deployment options #1013)
• Proposal - simplifying resource referencing (part 1) #2245
• Check if resource exists #4023

[kilasuit]

I'd like to demo / speak about this bicep adjacent repo I just published ARMTemplateComplexity which was linked to this issue & comment in arm-ttk repo

Eventually I want to expand this to properly score bicep code too

[Marc013]

How to create custom Bicep linting rules?

We have defined some Bicep coding guidelines specific to our context that we would like to validate while creating the Bicep code. Is there a solution to accomplish this (functionality like pwsh PSScriptAnalyzer)?

A guideline we have is:

• Define generic metadata

metadata generic = {
    synopsis: 'A brief description of the module or deployment template.'
    description: 'A detailed description of the module or deployment template.'
}

[jinkang23]

I'd like to get an update on the Deployment Stacks feature, timeline for public preview, general availability, etc.

There's a lot of desire/need from our organization to have stateful IaC and although Terraform is a good alternative, it would be very beneficial if our first choice was native first-party solution, Bicep. We are already part of the private preview, but our internal policies prevent us from using any tools not deemed generally available for production workloads.

[ChristopherGLewis]

What's the current plan for a better story on deleting resources via Bicep/ARM? There are a couple of items/discussions that have cropped up (#4259 , #2690 ) with references to Deployment Stacks but I'm not super comfortable with not having a native ARM delete.

The driver for this is the comparable story in Terraform - create a template, TF plan (see what will happen), TF apply (make it happen), TF destroy (remove what happened). We're starting to see a lot of work shift from native Bicep/ARM to Terraform for the "destroy" feature alone.

[alex-frankel]

@ChristopherGLewis -- can you help us understand the distinction between a "native ARM delete" vs what Deployment Stacks is going to provide?

[alex-frankel]

@Marc013 - the only way to create custom linter rules is to make a contribution to the bicep project itself. @StephenWeatherford demo'd the process last year:
https://www.youtube.com/watch?v=uj2RalNq4uk&t=1908s

Of course, this requires at least some C# experience :)

[ChristopherGLewis]

@ChristopherGLewis -- can you help us understand the distinction between a "native ARM delete" vs what Deployment Stacks is going to provide?

My thoughts on a ARM/Bicep native is to have a "Remove-AzTemplateResources" that takes the resources in a template and removes them. Same at the sub and MG level. While the plan for Deployment Stacks would allow for full lifecycle, this does nothing for existing resources.

I think the big thing I'm looking for is a story where I create a resource in Azure via the portal, then create a template and import the resource into that template using vscode's "import Resource ..." then running Remove-AzTemplateResources to clean up any resources defined in that template. This would be very sledge-hammer-ish, but it would be such an improvement.

Note this has to be new since "Remove-AzResourceGroupDeployments" removes the deployment, but not the objects deployed by the deployment...

[alex-frankel]

Stacks will allow you to "import" a resource into a stack by adding that resource into the template then re-deploying the stack. As long as the additional code does not change that resource's properties, the operation should be a no-op. At that point, you could run Remove-AzResourceGroupDeploymentStack -DeleteAll which would delete everything in that bicep file. Does that accomplish what you are looking for? We can of course talk more about this on Thursday.

[miqm]

Status of registry completions #9038

[ChristopherGLewis]

Stacks will allow you to "import" a resource into a stack by adding that resource into the template then re-deploying the stack. As long as the additional code does not change that resource's properties, the operation should be a no-op. At that point, you could run Remove-AzResourceGroupDeploymentStack -DeleteAll which would delete everything in that bicep file. Does that accomplish what you are looking for? We can of course talk more about this on Thursday.

It will certainly be a little less than ideal, but may be OK. From a usability standpoint, I like the idea of:

• grab a sample ARM/Bicep template from github, deploy it, use the resources, undeploy it

With Stacks, the story is:

• grab a sample ARM/Bicep template from github, deploy it, use the resources, add the resources to a stack, deploy it as a stack, remove it

Yes, the end result is the same, but its pretty complicated. And until all of the internet ARM/Bicep samples are converted to Deplyment Stacks, it's just adding confusion.

BTW I like az deployment group destroy as the opposite of az deployment group create and 'Destory-AzResourceGroupDeploymentgiven the very destructive nature. Unfortunatelydestroy` is an unapproved verb.

[WhitWaldo]

I'd like to talk about Azure container registries and how they're supposed to be accessed for Bicep deployments from Azure DevOps jobs. I've got a support ticket open (#2301050040002779) that's got three engineers stumped as to why I'm unable to authenticate (with a 401 response) to ACR from my DevOps deployment using a service principal with far more than sufficient privileges.

[slavizh]

@ChristopherGLewis you do not need convert anything to use Deployment stacks. You can take existing Bicep/ARM template and use it without modification.

[lsmith-apriva]

I think a "Delete Everything" nuclear option is not working along the lines of what Terraform can accomplish.
What I would wish for, is a mode where if you remove one resource from your existing script for objects already deployed, that BICEP would offer to tear down that one resource, not everything.

As it stands today, to remove a resource deployed by BICEP, you have to

1. manually delete it from Azure.
2. remove it from the BICEP (so it doesn't get accidentally re-deployed)

[slavizh]

I think a "Delete Everything" nuclear option is not working along the lines of what Terraform can accomplish. What I would wish for, is a mode where if you remove one resource from your existing script for objects already deployed, that BICEP would offer to tear down that one resource, not everything.

As it stands today, to remove a resource deployed by BICEP, you have to

1. manually delete it from Azure.

2. remove it from the BICEP (so it doesn't get accidentally re-deployed)

That is what deployment stacks will offer.

[Kaloszer]

I would like to ask about the status on #387 - optional parameters - MS Sentinel - Analytic Rule does not accept some null values and expects a value (but will accept not receiving that parameter...) - there's workarounds I think but this is quite a neat feature to cleanup code.

[alex-frankel]

I'd like to talk about Azure container registries and how they're supposed to be accessed for Bicep deployments from Azure DevOps jobs. I've got a support ticket open (#2301050040002779) that's got three engineers stumped as to why I'm unable to authenticate (with a 401 response) to ACR from my DevOps deployment using a service principal with far more than sufficient privileges.

@WhitWaldo - Instead of covering this in the community call, let's keep pursuing the support case. If the support engineers are not able to help you, they should continue to escalate and bring in the product team as needed.

[alex-frankel]

@lsmith-apriva / @ChristopherGLewis -- we demo'd the current private preview II capabilities of Deployment Stacks in the October community call:
https://youtu.be/tPrpsKVEhSU?t=1463

That jumps right into the demo, but you can go earlier in the video to learn more about the theory/design of deployment stacks. But @slavizh is correct -- stacks will work with any template/bicep file and a stack can delete any resources that were removed from a previous version of a stack (or you can nuke the whole stack).

@ChristopherGLewis I was specifically referring to the scenario of exporting from the portal. If you are starting with IaC from scratch, working with stacks should be straightforward.

[ChristopherGLewis]

@alex-frankel Agreed, if you are using stacks from the start, it's The Way™. I also think the key to Stacks that I was missing is that Stacks can use existing code - it's really just changing the deployment command and you then get full lifecycle management. I'm not sure how quickly we'll move to this approach since it's quite a bit of change, but this is much much better than Blueprints.

I'm actually curious about something that Brian Moore mentioned at 27:45 "The bulk delete API" - is this something that's exposed to us?

[alex-frankel]

"The bulk delete API" - is this something that's exposed to us?

@ChristopherGLewis -- I am not sure TBH, but just asked :)