AzOps Pull – Bicep

[SomilGanguly]

Update AzOps Pull to pull the exported templates in Bicep, is an added option to give customer more flexibility.

[tommysvensson0]

Hi guys, any update on this one?

[Jefajers]

Moving forward our long-term plans are in the following direction:

To expand AzOps capabilities by enabling Bicep file generation confidently with existing Pull operation (dependent on Bicep CLI) we have spent a few cycles experimenting with the bicep decompile workflow. We need the use of AzOps to be predictable/reliable to avoid a flood of community issues due to uncertainty in decompile quality and cause.

The main challenge we see pivots around the “best-effort” nature in the chain of “two” decompile events:

1. AzOps acts as the main “first” decompiler with “best-effort” targets by interacting with Azure and gathering the ARM resource and structures the information with the help of Jq to ensure the pulled ARM template file ideally results in a deployable asset (Push operation).

2. Adding the option to output the information to Bicep files with a “second” decompiler (bicep decompile) based on yet another “best-effort” chain creates a higher level of unpredictability and complexity during Pull / Push operation. The “results” of the decompile events 1 and 2 are both of a “best-effort” nature and puts increased importance of tests / traceability to say that at version X the following Y resource providers were Pulled and Pushed by AzOps successfully.

AzOps journey to add bicep support for the Pull operations hinges on the following items:

• Establish baseline of most used resource providers in the AzOps community today
  • Expand Jq templates where required to cover baseline
  • Expand AzOps automated testing to include those resource providers for ARM
• Add AzOps Bicep decompile support
  • Expand AzOps automated testing to include those resource providers for Bicep

The “best-effort” nature becomes less of an issue with the addition of establishing a baseline testing for popular resource providers and the AzOps community just as always can raise issues and introduce new providers.

Why not just test all the resource providers in Azure?

• Labor intensive to implement and maintain
• We want to spend time on RP’s that are used by the AzOps community

[StefanIvemo]

I think that we should look into using the "insert resource" function that's available in Bicep here. It will export the resource and clean up the template based on the Bicep type system to make sure that read-only properties and other noise is removed. At the moment it's only available in the VSCode extension, but it can be added to Bicep CLI as well. There is a feature request open to add it but it is not top priority at the moment, https://github.com/Azure/bicep/issues/5696.

In my opinion I would say that a baseline of most used resource types that should be prioritized can be skipped. If the export of a bicep template/decompile fails we could fallback to exporting an ARM template instead of Bicep.

[SimonWahlin]

I really like this suggestion by @StefanIvemo (although I would prefer bicep export over insert or import if implemented in bicep.

[BenjaminEngeset]

@StefanIvemo

I did not come across your comment before now, but this would be preferred. Using inbuilt logic from the binary would be to considerate as the most optimal.

I will highlight this for the Bicep-team (as you have done), but their backlog is huge.

Utilizing this, it will save AzOps team for creating and maintaining all the logic at least..

Sidenote:

Be able to prioritze .bicep over .json in the same folder when the resource declaration is identical. It seems like AzOps already has this in place, only the opposite way.

Run what-if against compiled bicep file > .json since it can't be proven trustworthy on .bicep. It seems like this is already in place by AzOps.

Would really be to get "rid off" (dream) human interaction with .json, after Bicep I've almost forgotten how to use it..