https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
b
Pulumi functions by building a representation of your desired state by interpreting your pulumi code first. Your pulumi code is executed to completion in order to build that desired state and dependency tree before any requests are made to your cloud provider. That is why resource outputs are promises, because they are not known at the time that you pulumi code is executed. That's also why your resources are declared synchronously.
p
Thats a resource output not a stack reference output. A stack reference output is static at time of reading.
b
I understand the resource outputs in general - they can and will change at runtime (as requests are made to cloud provider APIs). Stack reference outputs will not change at runtime - Pulumi just reads the state to get to them
b
I didn't realize he was asking about stack references in particular. Honestly I think that's just because they were written to function like the other resources. Again, I don't think that request to get those stack outputs is made right when your pulumi code is first executed, so those values also aren't known at that time. Maybe someone else can chime in. You're correct that it won't change when it is read, but that doesn't mean it is read before your other resources are declared. That request is still deferred until after your desired state is built.
b
so, a leaky abstraction of the internal implementation model? 🙂
b
how would you represent the output of a delayed asynchronous request if not a promise?
b
I don't see why it has to be async in the first place?
b
because your state could be stored in cloud provider blob storage, or in the pulumi API - both of which would necessitate an http request?
b
right, and it can't be a synchronous http request?
b
There's nothing preventing you from just awaiting the output in your pulumi code if you want. It's built into the dotnet sdk https://github.com/pulumi/pulumi/blob/5f9f38c9c955e32eb753ed13568dfddeda4e22df/sdk/dotnet/Pulumi/Resources/StackReference.cs#L92
b
I'll look into awaiting the stack reference, thanks!
l
Stack references are not read only at run time and are not guaranteed to not change during execution. There is nothing preventing you from getting a stack reference to a stack that is currently being `up`ped.
A requested output might not even exist at initial run time of your requesting stack, but might be available by the time the dependencies resolved and apply is completed.
Even if there was an assertion that the stack could not change once the stack reference is created, the stack state is usually in the cloud (in Pulumi's infra) so getting the value from there is asynchronous.
b
true, I didn't think about "reference state changed under my feet at runtime"
I just realised that I thought it won't happen because the stack reference on the stack that's being `up`ed will fail with "no such stack" because it won't be able to take the lock, no?
b
Locking isn't supported in every backend, It was recently added to file state backends but AFAIK may still require an environment variable to enable
b
true, but that's the plan anyway, right? To prevent this exact situation - a stack reference output changing under the feet of another stack that's referenced it, effectively making 
preview
and 
up
yield different results
b
well currently internally preview and up are separate actions. meaning even if a lock was acquired for the first action I don't think we're holding the same lock for the next action
if you checkout the Q4 roadmap though 1 of the high value adds is something akin to terraform plan. So that preview or a similar command can give you a tangible output that you can then provide to execute, and throw if the expected operations are different than the plan
b
I saw that, yeah, looks extremely useful!
28 Views
Open in Slack
PreviousNext
Powered by