ETA on languageVersion 2.0 support

[wouterroos]

Hi,

Are there any plans to support languageVersion 2.0 in the VSCode tooling?

Thanks,

[alex-frankel]

I don't believe there are any plans to support the new language version in ARM Tools. Can you help us understand what you are trying to do than you cannot accomplish with the bicep extension on the original bicep files?

[Neutrino-Sunset]

I'm not using Bicep files.

If you've effectively deprecated the Azure Resource Manager Tools by deciding not to support key new features, then it would be useful if your documentation flipping said so!

https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/overview

[alex-frankel]

Agreed that we need to document this better. There is a distinction between not supporting current features (which I would call deprecated) and not supporting new capabilities.

@puicchan / @mumian / @stephaniezyen - can we update the documentation to capture this level of detail?

[jordanmills]

Wait, so this extension is going to ignore anything new about ARM templates?

[alex-frankel]

Any new features being added to the ARM template language are entirely to support new bicep features. There are no new features being added to ARM Templates otherwise. We strongly encourage anyone using ARM Templates to migrate to Bicep. If there are blocking issues preventing that migration, we would love to better understand those.

[jordanmills]

That is horrible and must be reconsidered. I've found many cases where working with ARM templates is preferable or necessary and having syntax parsing, highlighting, and other support components for current versions, especially when they are clearly across Microsoft's docs, is critical.

[alex-frankel]

Do you happen to have some of those cases handy? Like I said, we really would want to understand any scenarios that are preventing migration. Would you be up for a call to discuss this in more detail?

Are there features in language version 2.0 you are looking to take advantage of? All of the current features in this extension that you are using will still continue to be supported.

[Neutrino-Sunset]

For starters Azure Template Specs don't support Bicep.

[alex-frankel]

The template spec CLI tools support creating/updating specs with bicep files. The ARM Template is still what you would see in the portal, but at that point it is more of a deployment artifact rather than a file you should be editing.

[Neutrino-Sunset]

The ARM template is what you would see in the Portal, and it is what you would get back if you export it too, and AFAIK no way to convert that back to the Bicep file you originally had. So if you use ARM files you can use a Template Spec as a repository for your deployments, whereas if you use Bicep you have to have some other process to manage them.

Looking at the MS IAAC Azure offerings I see:

1) The ARM tooling doesn't support language version 2 and isn't planned to be updated anymore 2) Bicep isn't supported in Template Specs and you can't convert ARM back to your original Bicep 3) Neither ARM nor Bicep support destroying the resources they actually created, both only support the teardown of an entire Resource Group

MS still doesn't seem to have anything that can do what Terraform does.

[jordanmills]

Do you happen to have some of those cases handy? Like I said, we really would want to understand any scenarios that are preventing migration. Would you be up for a call to discuss this in more detail?

Are there features in language version 2.0 you are looking to take advantage of? All of the current features in this extension that you are using will still continue to be supported.

One of mine is better stated above, and ties into the next one. ARM templates are native, and tooling to manage and troubleshoot them is critical. The tools to convert bicep to arm and back are far from perfect. They have quirks around function preference that lead to really awkward conversions. They can also take a valid ARM template, convert it to valid bicep, then convert it back into an invalid ARM template (I saw that one as recently as two or three days ago).

Retraining, especially over artificially forced obsolescence, will generate significant costs and ill will. We have to get developers and admins to do more training/learning on something everyone believed they already had down, which is going to have direct costs and indirect costs on taking them away from billable work.

Another big concern is invalidation of existing investments around infrastructure as code and CI/CD. Everything is already in ARM templates. But some genius is eventually going to decide that everything should be converted to bicep and kept in bicep, so there will be non-trivial costs in conversion and maintenance, that may or may not be realized in decreased costs for eliminating knowledge of ARM templates as a hiring requirement. But you'll still need staff familiar with ARM templates for extraction, conversion validation, and troubleshooting. So that's just a cost sink.

So what it looks like, especially at an executive or accounting perspective, is an ongoing march of post-investment costs for Azure. If we're going to keep paying like this, why not just pay it to move to AWS where things seem a lot more stable. If Microsoft does not think its own technology is worth ongoing investment, why should we invest in it?

To answer your question, the feature that seems most valuable is symbolic resource names. And yes I you think that will help.

[alex-frankel]

To clarify, there is no explicit push to migrate if you are happy with ARM Templates as they are today. The current functionality will still be supported. We completely understand that a migration to a new codebase is a non-zero cost both in the actual migration of code and re-education/training.

If there is more interest than expected in supporting symbolic name schema then we will need to take a fresh look at that and reconsider support for Lang Version 2.0. Thanks for clarifying that @jordanmills. @Neutrino-Sunset - is that also the functionality you are looking for?

Just as a word of caution, we would strongly recommend against treating Template Specs as a code repository. It is designed to be an artifact repository like NuGet or NPM. The source code for those template specs should still be in code repos like GitHub where you can branch, create PRs, look at commit history and diffs, etc. In that case, if you have converted to Bicep the source will always be there.

The tools to convert bicep to arm and back are far from perfect.

No dispute on this one. The intention of moving to bicep should be one-way. If you find that there are reasons to be going back-and-forth, it means we've screwed something up. Besides that Template Spec scenario, are there any other cases where you suspect you might need to go back and forth?

Lastly, regarding this statement @Neutrino-Sunset:

Neither ARM nor Bicep support destroying the resources they actually created, both only support the teardown of an entire Resource Group

We have recently introduced Deployment Stacks for exactly this purpose. It is in Public Preview. Please check it out and let us know if it is meeting your expectations. It does not require any changes to your Template code, but does require you change the CLI command you use to deploy. Deploying as a Stack is also supported from the portal.

[DoubleCouponDay]

2. Bicep isn't supported in Template Specs and you can't convert ARM back to your original Bicep.

try using the Azure CLI to convert it.

az bicep decompile --file arm.json

[mcdonamw]

I'm just now starting to learn ARM templates and I'm starting from the templates created in the portal. Trying to use them in VSCode with the ARM extension has led to warnings and me to researching how to get around them only to find this issue and no intention to support ARM any longer. Just my luck. I am using the Portal templates to learn all this stuff but now I have to re learn this stuff from the ground up or deal with conversions to Bicep on top of my initial learning as well? That stinks.