https://pulumi.com logo
Join Slack
Powered by
Is there currently nothing that can generate YAML ...
# general
m
Is there currently nothing that can generate YAML from a resource graph declared in a general purpose language? https://www.pulumi.com/docs/reference/cli/pulumi_convert/ -- seems to only take YAML as an input. I want to generate the YAML for my TypeScript project. https://github.com/pulumi/pulumi/blob/v3.40.2/pkg/cmd/pulumi/convert.go#L54-L65
Mucking with Pulumi AI
e
Very similar to the question from yesterday: https://pulumi-community.slack.com/archives/C84L4E3N1/p1683214645082219 In general we can't convert from programming languages to YAML
m
I wouldn't expect the conversion to be perfect. I would expect a general purpose language gets the resource graph calculated, and then the YAML is built from the resource graph and I fill in the gaps.
e
I do have thoughts on how we could do that, but it's not been a priority to work on. Generally we see people going from YAML to general languages, not the other way round.
Feel free to raise a request on our github for this though, I don't think we've got anything publicly tracking this.
m
Yeah, that's fair. I suppose my use case is to reel in the dev teams that ignore basic repository hygiene, and we don't want to automate dependency updates for.
For simple microservices that are basically event-based and maybe have an API Gateway, YAML seems like a much better approach for operations.
On the other side of the coin, we have projects that absolutely need a general purpose progamming language because of the complexity.
e
Have you considered writing component resource providers? They can be written in Typescript but then used in a yaml program.
This is how awsx works.
m
Yeah, and actually we've naturally started to move away from our 
pulumi-components
and the 
awsx
packages. The level 2 abstractions are double-edged sword, and the more your microservices rely on them, the more difficult it can be to push them forward in unison.
With the exception of autotagging and VPC resolution, and an RDS wrapper. Otherwise, we've been duplicating the long-form level 1 resources to promote more autonomy while staying aligned.
An example of a huge pain in the ass for this pattern was the MAJOR aws provider upgrade that changed how the provider reads configuration, essentially breaking portability between v4 and v5. It was a tedious and carefully planned upgrade that needs to happen same day across all the projects. You don't want to end up with a mix of v4 and v5 aws providers. We had to worry about upgrading 
pulumi-components
, 
pulumi-policy-packs
, then our microservices and finally 
shared-infrastructure
. Then you have to deal with the breakage and conflict between shared dependencies. If your components package also uses awsx, you're probably going to have a bad time if your versions mismatch between the consumer and the library.
e
I really would suggest raising an issue for this. We could probably do something to make this better but probably needs some more input and thoughts than slack is convenient for.
m
I appreciate the sentiment, but I don't believe any of the MAJOR issues I've raised, even to our Customer Success Manager have been addressed.
e
Oh that's never good to hear 😞 but you'll probably get a slightly different response directly on github. Firstly we get other users chiming in, but also that goes straight to engineering so if there's been any mistranslations because of CSM (rare but does happen) we get a new direct look at the issue. And then sometimes CSM have told engineering but they just are very hard issues to solve.
m
This issue has been open for 2 years, https://github.com/pulumi/pulumi-aws/issues/1366
Doesn't matter for us so much any more because we use SSO in an interesting way that lends itself to us being able to drop our shell wrapper script.
This is like a welcome mat though... literally the pulumi command is broken for users that setup their AWS IAM in a secure way. I get that it's really an issue with the underlying Terraform provider, but that's not a great excuse. Onboarding for devs was not a good look, I think it could have impacted sentiment, "Copy this shell script to make the IaC program with a funny name work"
e
I can't comment much to why there's auth issues with aws, not something I work on directly but I get the concern.
m
No worries, didn't mean to go off on a rant
e
I'd rather hear about issues than not so no worries 🙂
5 Views
Open in Slack
PreviousNext
Powered by