https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
w
The specific case I have in mind is dot net core config composition
I should be able to compose hierarchical config using multiple sources, including files and env vars etc, then hand that to pulumi...
I.e. Invert control of how config is managed
This makes even more sense given a pulumi runtime api when I could create a console app with generic host.
l
automation apis have write apis for config: https://pkg.go.dev/github.com/pulumi/pulumi/sdk/v2/go/x/auto?tab=doc#LocalWorkspace.SetConfig This might be helpful for writing a higher level config module (when this lands in dotnet of course).
w
Oh that looks very promising. Does it really need to write the config file or is that just a temporary thunk to the existing api? Another thought, it would be nice to have a declarative convention for secrets, combined with being able to pass all config as a json/yaml string. That way I can manage config myself and simply serialize to json/yaml to hand to pulumi. Not sure that would be practical though. Would be handled in dotnet using attributes on config class properties, combined with a special serializer.
l
LocalWorkspace
is designed around the CLI, but the underlying 
Workspace
interface makes no assumptions around where config comes from. I could imagine writing 
InMemoryWorkspace
, 
SQLBackedWorkspace
, etc.
Long term, the thought is that automation API will not use the CLI, and instead interface with the engine via RPC.
w
Cool. I really want this for dotnet! 🚀
In the meantime, I could still invert control of config if I only could set the config file from inside the running stack itself, before calling the deployment api...
@lemon-agent-27707 would the above work, or is the config read by the pulumi cli before shelling out?
Something like the following for dotnet:
Copy code
public static class Program
{
    public static Task<int> Main()
    {
        // TODO write Pulumi.<env>.yaml
        return Deployment.RunAsync<AwsStack>();
    }
}
l
In the traditional CLI driven model, the pulumi program is invoked with config specified as environment variables: https://github.com/pulumi/pulumi/blob/master/sdk/go/pulumi/run.go#L144-L147 So it's read by the CLI before invocation.
w
That's very interesting. For dotnet I see it ultimately delegates to IDeploymentInternal.GetConfig Unless I'm missing something, if Deployment.AllConfig was lazily initialized, then I could inject 
PULUMI_CONFIG
env var with my own json config! Specifically, I could overwrite it in 
Program.Main
before calling 
Deployment.RunAsync
. That would be a nice workaround if such a change was acceptable. What do you think?
l
I would say that what you are describing sounds possible, but you would be taking advantage of an undocumented implementation detail with no guarantees of stability 😁
w
Well, it won't work unless the 
AllConfig
property is changed to use 
Lazy<T>
, so I'd need some buyin...
Should I create an issue for further discussion? 😛
l
Sure, feel free to open the issue. Will be interested to hear input from others. I don't know that I fully understand your scenario but if you're trying to write some sort of higher level config orchestrator then automation api sounds like the right tool for the job. I don't believe we have an issue open for automation api for dotnet
w
Yeah that's my scenario. Pulumi config is not flexible enough and weak compared to built-in dotnet support. So I want to use full power of my framework and delegate resulting config to pulumi... and I don't want to have to wait for dotnet api automation support which looks to be quite a way off.
I did a quick test with the following:
Copy code
public static class Program
{
    public static Task<int> Main(string[] args)
    {
            var configJson = Environment.GetEnvironmentVariable("PULUMI_CONFIG");
            var config = JsonSerializer.Deserialize<IDictionary<string, string>>(configJson);
            config["infra:injected"] = "value";
            configJson = JsonSerializer.Serialize(config);
            Environment.SetEnvironmentVariable("PULUMI_CONFIG", configJson);
            return Deployment.RunAsync<AwsStack>();
    }
}
I can see the test value does actually get injected into 
Deployment.AllConfig
, however it's not reflected in the Pulumi web UI, which implies there's more devil in the details.
b
@worried-city-86458 Did you figure this out? I was messing with this also.
w
No, so I'm holding my breath for the dotnet automation api.
4 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by