https://pulumi.com logo
Join Slack
Powered by
Is there a way to pass a config via the CLI to mer...
# general
f
Is there a way to pass a config via the CLI to merge in with the file config during an 
update
?
w
Yes - you should be able to pass 
pulumi update —config
to include configuration along with an update. See https://pulumi.io/reference/cli/pulumi_up.html.
f
Does that merge in with the config or replace it entirely?
w
Should merge in.
f
The config flag for 
update
is documented as 
-c, --config stringArray
. What does 
stringArray
mean when called from the command line?
I took a guess and it appears it somewhat works, though the result is unexpected. I ran this command:
Copy code
pulumi update --config 'cloud-aws:externalVpcId=asd'
And it actually updated my stack config file to contain 
cloud-aws:externalVpcId
. I was expecting that it was merge in my CLI config options in memory and not actually update the config file.
w
Ahh - yes - in the current form this has the same effect as 
config set
along with 
update
. Curious to understand the scenario that motivates you to want to set configuration on the update but not persist it? How will you know what to do for the next update?
f
I want to use 
cloud-aws.Service
with a VPC created in code and the only way to configure that is via the config file. My plan was to create all my other infrastructure in project1, mark all the required 
externalVpc
config params as exports, and use them to 
update
the project, project2, that contains my 
Service
. Because the resources in project2 depend on project1, project2 cannot and should not be deployed without project1 being deployed. As a side note: I expected the 
--config
flag to do the merge in memory rather than mutate the file because if I wanted a file mutation I would've just used 
config set
.
w
I see - yes that makes a ton of sense. Really we need to support the ability to create an instance of the cloud framework parameterized in code instead of config. That’s something we’re looking into. Feedback on 
pulumi update —config
being a little surprising makes sense too.
Note - although it’s a little fragile - I’m pretty sure if you imperatively set 
cloudaws.config.externalVpcId
prior to constructing any resources from cloud that depend on the network, you can override this in code. I recall working with a user who was doing this a couple months ago. (This is exactly what we want to support in a more first class way as part of https://github.com/pulumi/pulumi-cloud/issues/601)
f
Cool, that feature would simplify life a lot! I'll give your suggestion a try tomorrow. Thanks.
I assume I need to do the imperative set in an 
.apply
.
Wait were you saying I'd be able to merge both of my projects into one and set the 
externalVpc
params prior to constructing the resources that require the network?
Because the 
cloud.Service
does not have any implicit dependencies on values from other resources, I believe I need to add some resources to the 
dependsOn
list, assuming that does what I expect 🙂
Trying that out now. Annoyingly, Pulumi still creates a default-vpc because it doesn't know that the externalVPC params are going to be set later.
This approach did not work. The 
cloud.Service
was created in the default-vpc that Pulumi created.
w
Hmm - okay - that's a shame. Definitely makes https://github.com/pulumi/pulumi-cloud/issues/601 even more important.
✔️ 1
5 Views
Open in Slack
PreviousNext
Powered by