https://pulumi.com logo
Join Slack
Powered by
Guys, I'm posting this here because it's something...
# general
f
Guys, I'm posting this here because it's something I believe a lot of us probably look for in Pulumi. (I'm not self-promoting here.) At work, I have been trying to build Terraform-like behaviour into Pulumi when passing around variables. You would all know we develop our resources with default values that only come back later and wish we had something that could easily overwrite them. Well, I have built something in Python to do just that. I've written about it here: https://theclouddude.co.uk/making-pulumi-feel-like-terraform-a-python-developers-guide I'd honestly love to have a chat about it and hear how many of you would like this functionality built into Pulumi. If it's quite a lot, I am considering rewriting my code into Go and checking it into the Pulumi repo to make it an actual feature of Pulumi.
m
I read your post, but I dont have a terraform background. I'm not sure I understand the use case. Pulumi has the yaml config that you can set this type of variable and has ESC where you can create them as environments. Is this to solve where you didn't make these parameters variable in the first place? if so, how will this work with ESC?
f
Thanks for reading my blog post @magnificent-eve-10499 🙂. I'm not sure I understand your question, though, sorry. Do you have any Pulumi docs you can point me to about ESC? I'll take a read and get back to you?
m
f
Thanks will take a look.
In reading this, it's not the same. ESC is equivalent to storing secrets in Azure KeyVault or AWS KMS. What I built was basically the same feature you have in Terraform, where you can make a resource and specify variable defaults and then use a tfvars file to change those defaults as you wish. Here's a link on how that works: https://spacelift.io/blog/terraform-tfvars Now there is a debate on why you would need a central resource. Some Devs like all their variable values to go into a centralised store others don't. The time where this is not useful is when you're building a brand new environment and to have it all run in one Apply you need something like pushing variable values through to make all your resources and have your code be reusable very easily so that a non-dev can make the environment and dev are not needed.
m
Pulumi already has this built in, no? https://www.pulumi.com/docs/iac/concepts/config/
f
No thats so that you can pass config options in it wont replace whats already there.
m
You can specify a default value when you 
get))
a configuration value.
f
You can but thats not going to replace default values you have put in.
m
I still don't get it. How is 
pulumi.Config().get("num_nodes", 12)
not replacing the default "12" with your desired value?
f
Yes now do that from yaml file...
your changing code
the idea is to pass values from the yaml through the code and into the resource
m
So you want to set default values in a YAML file?
f
Now have a dictionary of values and try and change the whole dictionary from the yaml file with config
no the point of the blog post was for it to work like terraform and change the default values of variables already specified with values from the yaml file. Making it work like Terraform with TFVars files.
m
Hmm, I still struggle to see the difference. Pulumi doesn't have a separate variable declaration like the canonical 
<http://variables.tf|variables.tf>
but integrates it into the program code. But in my mind (and in the way I use it) it's the same. In both TF and Pulumi I have to decide ahead of time which properties of a resource I want the user to be able to change. The user can then create a tfvars file or set the stack configuration to adjust these values as they please.
By the way, you might also find this recent discussion interesting: https://pulumi-community.slack.com/archives/C019YSXN04B/p1737367096242129
m
That is how I use it as well. I pass values from my yaml (ESC or IaC config) to my resources, but I develop them with default resources. Here is an example of how I dynamically build docker images passing the image tag and the appVersion of the software that will be installed in the Docker image with defaults, and only need to maintain it in one place. Either in the 
config.yaml
or centralized in the ESC config. What I am trying to understand here is how can I leverage what you have created in a way that improves on this workflow.
Untitled.ts
Open in Slack
PreviousNext
Powered by