This message was deleted.
# general
s
This message was deleted.
g
yes check the automation api. you then need to call
stack.config_set()
and then
stack.up()
to propagate the changes to the remote
d
Thanks Jan!
l
would dry run push the config and not execute the stack diff changes?
b
you shouldn't need to call up to propagate config with automation api. Just setting it should suffice, because under the hood it is just using the
pulumi config set
commands
l
does the automation api actually shell out to the cli commands, or just call the same library code that actual cli commands use
b
@little-summer-88406 currently it actually shells out to the CLI, which is why it requires that Pulumi CLI is installed on the host.
l
ah okay, is there plans for a deeper integration (in-process) without shelling out, I read something about a cwd bug the other day that sounded symptomatic of shelling out
b
yes, it was implemented as abstract as possible with the intention of replacing the CLI implementation with an implementation that calls out to the engine directly. There is definitely some quirks with spawning a child-process to invoke the CLI but there is still some work to be done before the engine can be invoked directly, because all of that work is written in golang so currently the CLI is being used as the go-between
g
@bored-oyster-3147
you shouldn't need to call up to propagate config with automation api. Just setting it should suffice, because under the hood it is just using the pulumi config set commands
As far as I know, this is actually not true. It only interacts with the local file until you ask for
refresh
or
up
. (IRRC we've already had this discussion before :))
b
@great-sunset-355 not sure what context that discussion was had. Maybe you're thinking of how the workspace manipulates project settings? But I wrote the initial .NET Automation API - so I know that it invokes
config set
commands right away. See here https://github.com/pulumi/pulumi/blob/562c9da008e29066451be157c80579f6f387a22d/sdk/dotnet/Pulumi.Automation/LocalWorkspace.cs#L521 For both
SetConfig
and
SetAllConfig
we are immediately invoking CLI
g
hmm interesting, when I do this in python
Copy code
from pulumi import automation as auto
from pathlib import Path

cwd = Path.cwd()
stack = auto.select_stack('staging', work_dir=str(cwd))
stack.set_config('var', auto.ConfigValue("value"))
It only sets the value locally in the file until I run
stack.up
Could this be a regression between languages?
b
possibly - let me look
g
I actually expected the behaviour you describe as well.
b
it looks like python is running the commands within those methods as well
so now I'm curious why you're experiencing a need to propagate. Maybe I'm misunderstanding how those CLI commands actually function
g
From the code you shared it's clear that
.NET
SDK executes CLI, while python SDK may be doing something else?
Let's ask the @red-match-15116 if they know?
b
I'm looking at the CLI code now and it looks like it might just be setting a value in the config map and not making any kind of IO request. So may just be a misunderstanding of CLI functionality on my part, if so, my mistake.
g
I'm 99% sure when I call
pulumi config set
via CLI it's set on both, local and remote
that's why I was surprised with the behaviour of automation API in python.
b
confusion
r
Hi!
pulumi config set
and therefore the relevant commands via any of the automation API sdks only set the configuration in your
Pulumi.[stack].yaml
file. To propagate it to state and to remote, you must run
up
or
refresh
.
But just confirming that there is no difference in how automation api
setConfig
works compared to
pulumi set config
because as @bored-oyster-3147 pointed out, it just calls the CLI under the hood.
b
word so just me being dumb. Thanks @red-match-15116! Guess that's especially important in Automation API where you might've made a temporary workspace and so your physical config file is transient, you'll want to make sure your changes propagate. Whereas traditional pulumi usage where you'll have a more permanent workspace / config file you're more sure that it will propagate eventually