aspire
aspire copied to clipboard
dotnet
Parameter naming flexibility
Is there an existing issue for this?
- [X] I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
The .AddParameter command today expects to find parameters in the Parameters configuration secftion or Parameters__ environment variable naming scheme.
We have a more complex configuration setup that looks like this:
ServiceConfiguration:SubService:AzureMaps:Key (for example) in the configuration file.
We can't currently define this as a Parameter for publishing, since that would require us to read it from Parameters:AzureMapsKey instead.
Describe the solution you'd like
Is there a way for AddParameter to function correctly for publishing that would allow us to keep the current naming structure and say, provide an environment variable ServiceConfiguration__SubService__AzureMaps__Key to satisfy the parameter? As it stands today, we have to create an appsetings.production.json file on deployment and ignore the best practice of using .AddParameter to satisfy these parameters (of which we have many).
Additional context
No response
#4429 Would solve this, I guess. Until then - does someone have an alternate way of approaching this - such as setting parameter value from a configuration item through some backchannel method?
Sounds like you're looking for AddParameterFromConfiguration from those set of methods. That won't pull the value for publish though as there's still a prompt that for the value (unless PublishDefaultValue is used).
unless PublishDefaultValue is used
But per our discussion, PublishDefaultValue would not result in pulling the value from config, right?
Though I guess now you can do:
builder.AddParameter("param", builder.Configuration["ServiceConfiguration:SubService:AzureMaps:Key"]);
Right, or more fully:
builder.AddParameter("param", builder.Configuration["ServiceConfiguration:SubService:AzureMaps:Key"]).PublishDefaultValue();
Kind of ugly, though.
Though I guess now you can do:
builder.AddParameter("param", builder.Configuration["ServiceConfiguration:SubService:AzureMaps:Key"]);
Yes, this is a good solution now, and seems more in line with how the configuration system in .Net works on a whole, as this would cover all use cases of where the parameter is actually stored (config file, environment variable, and so on).
@pedershk is your goal to have the value coming from config be published? Or is it only to be used in Run mode?
@pedershk is your goal to have the value coming from config be published? Or is it only to be used in Run mode?
Ideally both. During publishing (GH Actions) it would be nice to set Environment variables to satisfy Parameters - in addition to what's been discussed here about their placement in Configuration.
Basically the ability to treat Parameters as if they were just another dotnet Configuration item.
Ideally both. During publishing (GH Actions) it would be nice to set Environment variables to satisfy Parameters - in addition to what's been discussed here about their placement in Configuration.
That's an azd feature that already exists today.
@vhvb1989 did we document this yet?
Ideally both. During publishing (GH Actions) it would be nice to set Environment variables to satisfy Parameters - in addition to what's been discussed here about their placement in Configuration.
That's an azd feature that already exists today.
@vhvb1989 did we document this yet?
Yes. I'm aware that it exists in general, but using it with Parameters today requires the Parameters__Parameter syntax. The suggestions in this thread linking it to Configuration system would work better than how it works today for us.
I think that changes the feature request. We need to describe the name of the environment variable where this parameter will come from in publish. The default value isn't what you want, nor is it the configuration key as it doesn't apply in deployment scenarios.
I like the idea though but it's not a default value, it's name of the env variable from which to get the default value.
@davidebbo This adds another pivot to the many variables 😄
Sorry to complicate things, but not sure what you mean here. If the Parameter is bound to the Configuration system like suggested - wouldn't that use environment. Variables by default if they're enabled for use in the configuration system?
The problem occurs when default values are secrets. They can't appear in the manifest and that is what this API does. It embeds the default value in the manifest so that tools like azd can bake that default value into the bicep parameter.
What you want is to instruct the tool that there's a value stored somewhere externally. You want to tell it what the configuration key is at deployment time. The problem is, the deployment tool isn't reading IConfiguration, it has the manifest and that must instruct it where to look to get the value.
builder.AddParameterFromConfiguration("param", "ServiceConfiguration:SubService:AzureMaps:Key")
.PublishAsEnvironment("MAPS_KEY");
Something like the above.
@davidfowl what would the manifest look like when doing this? Would it be something like (making up some env syntax):
{
"type": "parameter.v0",
"value": "{pass.inputs.value}",
"inputs": {
"value": {
"type": "string",
"default": {
"readFromEnvironment": "MAPS_KEY"
}
}
}
}
And then whoever consumes the manifest would know to look up the MAPS_KEY env for that value?
And note that what you have above would also need to work with:
builder.AddParameter("param").PublishAsEnvironment("MAPS_KEY");
But it should throw for any non-config scenario. An alternate design it to have (and same for AddParameterFromConfiguration):
builder.AddParameter("param", publishAsEnvironment="MAPS_KEY");
Which would prevent trying to use this on non-config overloads. In fact, it would be symmetrical to the publishValueAsDefault param we added for code values.
If we agree that a parameter (publishAsEnvironment, or whatever we call it) works better than a separate call, I can start working on it.
But we should also start the conversation about coming up with the right manifest schema for this. /cc @vhvb1989 @mitchdenny. What I have above ("readFromEnvironment": "SOME_ENV_VAR") is just some random thing I came up with for illustration.
Actually, let's step back. Instead of explicitly having to state that the value can be set via some env variable, why not just say that in azd deploy, any parameter value can be set via environment, or equivalent command line switches?
This way, there is no change to Aspire, and it's generally available on all params. What's the drawback?
Actually, let's step back. Instead of explicitely having to state that the value can be set via some env variable, why not just say that in
azd deploy, any parameter value can be set via environment, or equivalent command line switches?This way, there is no change to Aspire, and it's generally available on all params. What's the drawback?
Agreed, that's the behavior I was expecting when first starting to explore parameters, to be honest.
I really do think mapping parameters to environment variables is a deployment tool concept.
Undocumented features:
Long thread to read through. 🤯 Would be nice to have a concise summary of what the feature is somewhere. Though above, @pedershk suggests that this azd feature as it exists today is not ideal?
I really do think mapping parameters to environment variables is a deployment tool concept.
Right, I think we're saying the same thing, and if so that there is no Aspire work needed here.