This message was deleted.
# generals
sparse-intern-71089
05/18/2021, 1:58 PMThis message was deleted.
b
brave-planet-10645
05/18/2021, 2:05 PMIf you wanted to use Pulumi config, you could have a project / stack that was just configuration, output all the config values and then consume them as stack references in other projects/stacks
g
green-hair-25935
05/18/2021, 2:08 PMwhat if I want to have common config within 1 service (common to all stacks but specific to 1 service). I would like to keep this common config inside the service, not in separate project
e
echoing-angle-67526
05/18/2021, 2:08 PMYes, that would work but I was hoping that I could do this without creating a new project/stack for each project. I also took a closer look at the automation api and doesn't look like I can use this when using the pulumi cli.
b
brave-planet-10645
05/18/2021, 2:10 PMThe other way would be to make use of the fact you're writing code and have a package that had a load of constants in it that you could share
e
echoing-angle-67526
05/18/2021, 2:12 PMthat's an option we've considered for configurations that go across all projects. what would be nice is to be able to see these configs in the pulumi console for auditing, debugging, etc.. i guess there isn't a way to currently do this?
echoing-angle-67526
05/18/2021, 2:14 PMthe problem is not being able to use shared configs but getting them in the console. i can create a github issue with this request if the capability is currently not there.
b
brave-planet-10645
05/18/2021, 2:16 PMI would always suggest creating an issue if we're not allowing you do what you want, and this isn't the first time I've spoken about cross-stack config
e
echoing-angle-67526
05/18/2021, 2:19 PMi believe there is already an issue about this: https://github.com/pulumi/pulumi/issues/2307
and one for configs in general: https://github.com/pulumi/pulumi/issues/4604
but i will create one specifically for being able to set configs from the Config class.
b
brave-planet-10645
05/18/2021, 2:21 PMYou can set config in the config class for the stack you're in
brave-planet-10645
05/18/2021, 2:22 PMSorry, I missed that at the beginning
brave-planet-10645
05/18/2021, 2:22 PMSorry, no you can't
brave-planet-10645
05/18/2021, 2:22 PMnot in "normal" code
brave-planet-10645
05/18/2021, 2:22 PMYou can in automation api
e
echoing-angle-67526
05/18/2021, 2:23 PMbut i don't think you can use this api at the same time you runnig your program from the pulumi cli?
b
brave-planet-10645
05/18/2021, 2:26 PMYou can run pulumi programs through the automation api, but you're right about the CLI
👍 1
e
echoing-angle-67526
05/18/2021, 2:27 PMg
green-hair-25935
05/28/2021, 8:27 PMHi Piers, it looks like pulumi insists on presents of Pulumi.stack.yaml ( for example Pulumi.dev.yaml) be present when 'pulumi up' called. We want to generate this file at runtime. I tried to create this file as a first step the pulumi script, before calling new pulumi.Config();, but it's already too late, it picks values already there. Is there a way to enforce pulumi to reload values before continue with deployment?
b
brave-planet-10645
05/28/2021, 8:38 PMYou can have an empty stack config file, there doesn't have to be anything in it
e
echoing-angle-67526
05/28/2021, 11:21 PMWhat we wanted to do is dynamically create the Pulumi.dev.yaml. Our pulumi program reads in a config.common.yaml and a config.dev.yaml files and then merges these two files together and then writes it to Pulumi.dev.yaml. We then read the configs by calling new pulumi.Config(); We were hoping it would read the new stack config file we created but it looks the Config class uses the stack configs that were present when pulumi up was called and ignores the file that we created.
echoing-angle-67526
05/28/2021, 11:29 PMif looks like if we want to leverage the pulumi.Config api for reading in stack configs we need to generate the Pulumi.[stack].yaml file before we call pulumi up.
echoing-angle-67526
05/29/2021, 12:51 AMit would be nice if you could have a pre-pulumi-up hook that executes before the pulumi up code. I guess you could do this with the automation api but it seems overkill for just this use case.
g
green-hair-25935
05/29/2021, 1:30 AMhere is more details:
green-hair-25935
05/29/2021, 1:32 AMPulumi.dev.yaml does not exist before run. When run first we create this file and dump content of it to console. Only after that we call 'new pulumi.Config()'.
green-hair-25935
05/29/2021, 1:33 AMat that point Pulumi.dev.yaml file is in place and has correct values. Wehn we run 'pulumi up' second time it will use it and it works fine. Here is cleaned up (hello world type) code
green-hair-25935
05/29/2021, 1:42 AMit looks like when pulumi starts it loads Pulumi.dev.yaml before new pulumi.Config() called. Is it possible to force it to reload configs?
b
brave-planet-10645
05/29/2021, 5:51 AMHave you looked at Automation API? I don't think what you're asking is possible outside of that.
g
green-hair-25935
05/29/2021, 3:40 PMThanks. I will check
e
echoing-angle-67526
05/30/2021, 1:56 PMUsing the automation API you lose all the features of the CLI as well as all the third party integrations. I found this issue that documents some of the shortcomings: https://github.com/pulumi/pulumi/issues/5538 and suggests a solution: https://github.com/pulumi/automation-api-examples/tree/main/go/inline_local_hybrid which we will look at.