Terraform-provider-azurerm: azure template format to tf template format converter tool

[singularit-io]

This is a feature request:

I would like to have a simple but very handy Azure template to terraform .tf file converter https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-authoring-templates

Meaning, you take a random template example from the Azure site, say: to create a VM or whatever, you run the converter and pass the said azure json template file path as an argument, and it produces a .tf file for you that will generate the exact same resource, but the Terraform way :) So you get all the benefits of using terraform: declarative state of the infra, more readable code, one single language type for managing multiple infras, etc etc...

Why ?

Right now, for example, az data lake is not implemented or az service fabric either... So I still need to work with Azure templates as well as Terraform files to get things done - I have deliverables and dates to respect and can't wait for your next releases so you guys get in synch with the more recent Azure offerings.

IF I had a way to tell my IT director, or the other architects: hey guys, you know what, no problem let's "patch" the missing feature with a separate job in our CD tool that will install this missing terraform resource, and therefore, missing part of the infra, with like one or two different Azure templates. When they (you guys) push the missing resource in the next terraform versions, we only need to run this converter script and we are back to normal with a uniform LOTR ring kind of tool to rule them all, our life is simpler, we can reuse code that plays with the terraform tf files in our automation stack (yes, we metaprogram .tf templates and then apply the changes automagically - but, I diverge - let's remain focus on the value of this).

That way I have some kind of peace of mind that although the terraform azurerm provider is not up to date with the current recent azure offerings, it's super easy to convert the missing resources back to .tf files/hcl language, as soon as you guys push the new resource for the azurerm provider. That way, I know that my automation scripts will eventually all be using terraform, and I can accept to do some parts of my automation in a less than ideal way, knowing that eventually I will be able to refactor my infra code with ease and ensure everything is managed by terraform, and not a mix and match of powershell patches here and there that will remain forever here because in the end I won't have the time or maybe won't even be there when the new resource is added to terraform, and yadda yadda.

Before closing this because it is a duplicate of a closed ticket, please consider the following:

To me it appears like a very quick win that becomes a selling feature: you can convert azure templates to terraform, meaning the goto for a more mature DevOps team that already uses the default microsoft ways becomes lessened. Meaning better adoption rates and another selling factor.

I could develop it myself but TBH that (to the least) partly defeats the purpose of using Terraform: if I need to change back what my teams did because of a missing feature to get uniform ways to modify my stack programmatically, I may as well use Azure templates and code once to do what I want... And I guess the "we use 5 different tools because no one tool is compatible enough with our stacks" problem will be something my colleagues will deal with once my contract is completed, which would be a shame if you ask me, because as an automation architect, the time is NOW to do things cleanly for my customer, but in the end I have delivery dates to meet and this kind of little issues can become a decision critical item in using terraform or not, in the end - is it really compatible or eventually compatible, or eventually compatible with trouble, that is the question - and my IT director answer on whether to use terraform or not will highly depend on such factors.

Another sub idea: should you invest more seriously into this, here is what you could do to make this tool even more valuable: make it multi provider (so you can have a more universal tool that converts also cloudformation templates to .tf, etc etc) then you keep track of errors running the scripts (most likely the errors would revolve around this: "hey I can't convert this cloudformation template resource to a hcl equivalent, it's not implemented yet"), and remotely pull statistics out of those errors your users face when using the tool. That way it would be super easy for you to see where you need to put work on: it would act as a monitoring tool for most critically missing features. Again you ensure that all supported resources become converted, and for the missing ones, you keep them as is in the output file, commented below in the file or something, so the tool converts what it can, and then for what it cannot, the guys can create a separate file and still run it with their in-house tool such as cloudformation azure etc and you guys know exactly how many times a missing resource would be useful to one of your terraform users (or your eventual terraform customers that would like to switch from say cloudformation or azure templates to terraform to manage their infra).

I hope my point is clear.

Thanks !

[tombuildsstuff]

hi @singularit-io

Thanks for opening this issue :)

So we have no plans to create a tool for converting ARM Templates to Terraform code - there's a number of reasons for this (for instance, how do we handle fields which have been removed but are still submitted via an ARM Template? This would also become a cat-and-mouse game of trying to ensure the two products are in sync which is time we could be spending elsewhere).

Right now, for example, az data lake is not implemented or az service fabric either... So I still need to work with Azure templates as well as Terraform files to get things done - I have deliverables and dates to respect and can't wait for your next releases so you guys get in synch with the more recent Azure offerings.
IF I had a way to tell my IT director, or the other architects: hey guys, you know what, no problem let's "patch" the missing feature with a separate job in our CD tool that will install this missing terraform resource, and therefore, missing part of the infra, with like one or two different Azure templates. When they (you guys) push the missing resource in the next terraform versions, we only need to run this converter script and we are back to normal with a uniform LOTR ring kind of tool to rule them all, our life is simpler, we can reuse code that plays with the terraform tf files in our automation stack (yes, we metaprogram .tf templates and then apply the changes automagically - but, I diverge - let's remain focus on the value of this).

That said - we have a couple of solutions built into Terraform which (mostly) do this - the first being Import support via terraform import which allows an existing resource to be brought into Terraform's Statefile. In a future version of Terraform it's planned that this will also generate the associated Terraform Configuration for the existing resource. The azurerm_template_deployment resource allows provisioning of resources which aren't yet available natively in Terraform by provisioning an ARM Template; in this instance you'd be able to integrate Terraform with ARM Templates for the resources which don't yet exist - and thread Terraform variables into the ARM Template and use the outputs of any ARM Templates within Terraform.

Another sub idea: should you invest more seriously into this, here is what you could do to make this tool even more valuable: make it multi provider (so you can have a more universal tool that converts also cloudformation templates to .tf, etc etc) then you keep track of errors running the scripts (most likely the errors would revolve around this: "hey I can't convert this cloudformation template resource to a hcl equivalent, it's not implemented yet"), and remotely pull statistics out of those errors your users face when using the tool. That way it would be super easy for you to see where you need to put work on: it would act as a monitoring tool for most critically missing features

So we have an internal roadmap for the AzureRM Provider we're working on making more public - in addition to this we also plan our work based on customer demand, either through Github (sorting by 👍 on issues/feature requests) or through our support channels.

Thanks!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!