https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
g
Can you elaborate on this?
f
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
I see. Interesting...
thinking
f
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
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
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
Doesn't sound like complaining. :)
In general, please open issues for any feature requests like this.
f
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
You're welcome and thanks for the feedback!
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by