https://pulumi.com logo
#general
Title
# general
n

numerous-garage-30550

06/04/2020, 9:25 PM
Can somebody help with T-shirt-sizing a following work (I'm willing to do it myself). For some weird reason which is not interesting, I need to have an option to generate standalone ARM template for pulumi stack to be used for performing actual deployment step. I'd like to re-use if possible all azure.* object model (without creating a new provider from scratch) but have something underneath translating that to ARM template instead of usual path. I do understand that ARM template is very limited in expressiveness so not everything would be even possible if this option is used.
w

white-balloon-205

06/06/2020, 10:09 PM
Not sure if this got answered elsewhere - but I'll share a few thoughts. First - there is unfortunately no easy way to do this currently. That is fundamentally for two reasons: 1. The Pulumi/Terraform resource provider resource model is not 1:1 with ARM - property names are different, property shapes are different, resources are combined/split, and a number of other differences. 2. The Pulumi/Terraform resource provider makes granular Create/Read/Update/Delete ARM API calls in it's implementation instead of lowering into ARM templates 3. The Pulumi deployment orchestration model itself alllows code to run intermixed with resource operations - so in a model that dumps an ARM template for creation elsewhere - you fundamentally can't have anything non-ARM depend on those outputs - which somewhat breaks the Pulumi model. That said - we have implemented the moral equivalent of this feature for Kubernetes (https://www.pulumi.com/blog/kubernetes-yaml-generation/). Our Kubernetes support doesn't have issue (1) above (it's a full and faithful mapping of the Kubernetes API schema). But it does have problems (2) and (3). (3) isn't a huge deal (just limits what you can do if you use this mode). So the biggest thing you would need to support this is to modify the Pulumi Azure provider to not make calls to Azure on CRUD operations, and instead CRUD against a local disk ARM template. However, because of (1), you would also need to maintain a complex mapping of resources and property names and property shapes to convert between the Pulumi/Terraform resource model and the ARM resource model. Not impossible, but not simple. We are doing early thinking around a more "native" Azure provider experience - which would among other things make this much easier - though we don't have any concrete timelines on that yet.