https://pulumi.com logo
b

billions-xylophone-85957

10/06/2021, 2:41 PM
A generic design question: why is a stack reference output an instance of
Output
? Stack reference outputs are read-only at runtime and they don't change during the execution, right? Why is it a promise then?
b

bored-oyster-3147

10/06/2021, 2:49 PM
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

prehistoric-kite-30979

10/06/2021, 2:57 PM
Thats a resource output not a stack reference output. A stack reference output is static at time of reading.
b

billions-xylophone-85957

10/06/2021, 2:57 PM
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

bored-oyster-3147

10/06/2021, 2:59 PM
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

billions-xylophone-85957

10/06/2021, 3:15 PM
so, a leaky abstraction of the internal implementation model? 🙂
b

bored-oyster-3147

10/06/2021, 3:19 PM
how would you represent the output of a delayed asynchronous request if not a promise?
b

billions-xylophone-85957

10/06/2021, 3:21 PM
I don't see why it has to be async in the first place?
b

bored-oyster-3147

10/06/2021, 3:22 PM
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

billions-xylophone-85957

10/06/2021, 3:25 PM
right, and it can't be a synchronous http request?
b

bored-oyster-3147

10/06/2021, 3:29 PM
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

billions-xylophone-85957

10/06/2021, 4:19 PM
I'll look into awaiting the stack reference, thanks!
l

little-cartoon-10569

10/06/2021, 8:29 PM
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

billions-xylophone-85957

10/07/2021, 8:55 AM
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

bored-oyster-3147

10/07/2021, 6:25 PM
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

billions-xylophone-85957

10/07/2021, 6:27 PM
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

bored-oyster-3147

10/07/2021, 6:28 PM
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

billions-xylophone-85957

10/07/2021, 6:30 PM
I saw that, yeah, looks extremely useful!
3 Views