https://pulumi.com logo
Powered by
f

flat-insurance-25294

01/25/2020, 2:02 AM
Is someone at pulumi working on saving values? We keep running into issues because this is missing. Something like storing previously used AZ zones becomes hard unless you hardcode the zones themselves.
g

gentle-diamond-70147

01/25/2020, 2:04 AM
Can you elaborate on this?
f

flat-insurance-25294

01/25/2020, 2:07 AM
Yes sir! On initial deploy we supply 3 AZ for the RDS cluster. The way we get the AZ is by using 
pulumi.getZones({state: "available" }).names.slice(0, 3)
which then uses 
aws ec2 describe-availability-zones --region us-east-2
Internally I assume. We want to make sure these values are cached for future usage. So it would be nice to store which AZs were used, because on future 
pulumi up
it might different zones. Now, assume a zone is down
If it gets different zones, then RDS will get different values and trigger an update when it shouldn’t.
Way to solve this would be to pass an argument to 
RandomShuffle
not to update the random when the values change. It seems counterproductive, so it should be opt in. This would help tremendously.
g

gentle-diamond-70147

01/25/2020, 2:11 AM
I see. Interesting...
thinking
f

flat-insurance-25294

01/25/2020, 2:13 AM
It think fundamentally Pulumi is awesome, it’s 90% perfect. The rest of the 10% we have to hack ourselves outside of Pulumi. It’s missing stuff like Runtime creating stacks, storing/caching values, default taggig every resource created without supplying 
tags: merge(defaultTags, {someOther: value}
g

gentle-diamond-70147

01/25/2020, 2:16 AM
Regarding storing/caching values... I think it's an interesting idea. I don't think it's one we've discussed before. Without this, I think the way to not hit the issue you describe is to use 
ignoreChanges
(https://www.pulumi.com/docs/intro/concepts/programming-model/#ignorechanges) when the zone id is used. This would ignore any changes to the values that are returned from that lookup and effectively act as a cache (more or less).
❤️ 1
But it's an interesting idea, so that you don't have to worry about setting that. Would you mind opening an issue on that at https://github.com/pulumi/pulumi/issues ? Your zones example is a good one, but any others you can share would be good too.
f

flat-insurance-25294

01/25/2020, 2:17 AM
that’s useful to know, thank you.
I think a colleague of mine is working on a ticket related to changes required in general, not just caching values. Our stance is there is a design flaw in how stacks work to make Pulumi effective for CI/CD usages. It’s somewhat related to storing things arbitrarily in a 
get_or_set()
style mode. I know it sounds like we’re complaining, but that’s because it’s almost there to perfect, with such low hanging fruit(s).
g

gentle-diamond-70147

01/25/2020, 2:20 AM
Doesn't sound like complaining. :)
In general, please open issues for any feature requests like this.
f

flat-insurance-25294

01/25/2020, 2:21 AM
Sure, but I’m usually concerned I might have missed something or misunderstood. I wasn’t aware of the ignoreChanges params for instance which helps for certain instances. Wonder if those work with RandomShuffle for instance. Just wanted to clear any ambiguity, we’re happy customers, on the free plan will move to paid once we got more devs. It’s just us three now using a single account but each dev gets their own stack + staging + prod.
Thank you again!
g

gentle-diamond-70147

01/25/2020, 2:25 AM
You're welcome and thanks for the feedback!
Powered by