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

millions-furniture-75402

05/05/2023, 11:32 AM
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

echoing-dinner-19531

05/05/2023, 12:12 PM
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

millions-furniture-75402

05/05/2023, 12:14 PM
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

echoing-dinner-19531

05/05/2023, 12:15 PM
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

millions-furniture-75402

05/05/2023, 12:15 PM
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

echoing-dinner-19531

05/05/2023, 12:18 PM
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

millions-furniture-75402

05/05/2023, 12:19 PM
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

echoing-dinner-19531

05/05/2023, 12:25 PM
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

millions-furniture-75402

05/05/2023, 12:26 PM
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

echoing-dinner-19531

05/05/2023, 12:31 PM
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

millions-furniture-75402

05/05/2023, 12:31 PM
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

echoing-dinner-19531

05/05/2023, 12:36 PM
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

millions-furniture-75402

05/05/2023, 12:37 PM
No worries, didn't mean to go off on a rant
e

echoing-dinner-19531

05/05/2023, 12:37 PM
I'd rather hear about issues than not so no worries 🙂
4 Views