Closed mitchdenny closed 8 months ago
/cc @davidfowl @ellismg
Another dimension to these prompt mechanics is how they work for local development. Even though we don't generate the manifest for local execution, we do have requests coming in from folks who want to have some secret centrally managed which they share across their apps. Using builder.Configuration[...]
is kind of clunky but works.
Once the secrets work is done, azd should be able to do this. Putting this in preview 3 but I think the work left to do is on the AZD side.
Tracking issue: https://github.com/Azure/azure-dev/issues/3189
@ellismg its important that when the enhancements are made to handling the "inputs":
field, that the behavior isn't limited to just secret resources.
@ellismg its important that when the enhancements are made to handling the "inputs": field, that the behavior isn't limited to just secret resources.
Agree.
This feature should work with any resource, but we will primarily use it with parameter.v0
resources.
@ellismg do you have a mirror of this issue over in the azd repo.
In preview 2 we shipped the ability to tell the deployment tool the generate a random password for a particular resource, here is an example:
Note the
password
input with the default value set togenerate
. Prompting would be the absence of a default, for example:In this scenario the deployment tool would pause and prompt for the value. The deployment tool may persist the value and may provide a mechanism to provide the value in advance for CI/CD scenarios (both recommended).
To fine tune the prompt, an additional field would be added with the name
"prompt"
which would allow the prompt that is presented to the user to be fine-tuned.This is a simplistic example, but the
prompt
field could be expanded to support things like creating pick lists and simple validation rules. Some resource types which are intrinsically linked with a particular cloud (e.g. Azure OpenAI) might even have the ability to have a resource picker (with fallback behavior).This particular feature will become important when introducing the concept of app wide secrets where a secret is shared between multiple services. In cases like this we might have a resource defined as follows:
Here the deployment tool would notice that
webhookendpoint
(an app) references the shared secret, and the shared secret in turn defines an input field for its value. If deployed using a tool likeazd
this would result in a keyvault being created calledmysecretstore
containing a secret namedgithubsharedsecret
with its value provided by the user whenazd up
is invoked.The environment variable defined on the
webhookendpoint
project resource would be bound to keyvault using this mechanism.Different target environments might have different analogues.