https://pulumi.com logo
#general
Title
# general
f

full-dress-10026

09/27/2018, 11:04 PM
Is there a way to pass a config via the CLI to merge in with the file config during an
update
?
w

white-balloon-205

09/28/2018, 1:34 AM
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

full-dress-10026

09/28/2018, 1:35 AM
Does that merge in with the config or replace it entirely?
w

white-balloon-205

09/28/2018, 2:02 AM
Should merge in.
f

full-dress-10026

09/28/2018, 4:00 AM
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

white-balloon-205

09/28/2018, 4:08 AM
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

full-dress-10026

09/28/2018, 4:15 AM
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

white-balloon-205

09/28/2018, 4:17 AM
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

full-dress-10026

09/28/2018, 4:33 AM
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

white-balloon-205

09/28/2018, 5:28 PM
Hmm - okay - that's a shame. Definitely makes https://github.com/pulumi/pulumi-cloud/issues/601 even more important.
✔️ 1
4 Views