Add azd option to be prompted for config values again

[dluc]

I'm using Aspire to deploy a project to Azure. The first time I run azd up I get prompted for a few questions, for instance

Apparently, there's no way to go through these questions again. One is expected to understand how to manage manually these values inside the .azure folder. A hacky workaround might be creating a new environment, or deleting the folder every time.

Please add an option to have those questions asked again, or, even better, change azd up to always ask the questions, showing the current values, given that there's already a --no-prompt to skip the questions if one needs to.

Thanks

[ellismg]

Thanks for opening the issue, @dluc!

You're right that we don't have a good story to reconfigure these values today - you need to create a new environment (which would mean redeploying new copies of all the infra). If you want to live dangerously, you can edit the config.json file stored inside the environment directory, to change the value of the infra.parameters.<name-of-the-parameter> (or remove it, and azd will prompt on the next step). This isn't documented because we don't expect folks to do this (rather we should be building the UX that this issue notes is missing) but it's how the system works today - so I'm sharing it with you in case that helps you workaround the issue.

I'm not sure that's we'd want to change the behavior of azd up to re-prompt (even with something like --no-prompt) for UX reasons, but we should provide a way to reconfigure these (or ignore the saved options).

@weikanglim - Interested if you have any thoughts as to where this configure command might live. I could imagine azd infra config which is the entry point to some UX experience. In the Aspire world, folks can add arbitrary parameters to the bicep that is generated by Aspire and these are the values that get prompted for (and azd infra config would modify). Are there UX patterns you're developing here that we should try to follow or do you see the shape of this problem at all on your end?

[weikanglim]

Agreed with @ellismg on a very great explanation here on how the system works here today.

Please add an option to have those questions asked again, or, even better, change azd up to always ask the questions, showing the current values

@dluc - I'm wondering in your case, would there always be a disjoint set of parameters such that:

1. Some parameters should always be prompted, i.e. 'clientId'
2. Some parameters should always be saved, i.e. 'authority'

If this is the case, perhaps having the ability to annotate the parameters could help with the overall experience.

Interested if you have any thoughts as to where this configure command might live

@ellismg - shooting from the hip here: I don't know if azd env config sounds any better than azd infra config... but here's the story I currently tell myself around primitives / concepts in this area:

1. When provisioning infrastructure, there are Inputs that a user can pass in. Like any other program, these Inputs should be overridable at the command line invocation.
2. When provisioning recurringly, a user may want to store these Inputs somewhere for workflow efficiency. Additionally, a user may want to exploit the fact that dev / int / prod instances that may deserve different values for Inputs. This is where Config come in; and perhaps it warrants being stored as part of the Environment.

I could also see that we start from Config stored under Infra (root) that is inherited by all Environment by default, then allow overlayering -- it's perhaps a tough call to make, some experimentation here would help understand the UX tradeoffs between the two.

For both Inputs and Config, they should minimally be hierarchically namespaced key-value pairs and addressed the same way. For example, if we were using . as the hierarchical separator, one should be able pass in --input path.to.my.key=MY_VALUE, or store similarly as azd env config set path.to.my.key MY_VALUE. Treating these as namespaces should allow examining a subspace of configuration, i.e. azd env config show path.to to show a config subtree.

[weikanglim]

Just putting this out here: another small UI tweak we could make that adds a single prompt to the happy path, that opens up configuring the save behavior for values:

? Enter value for 'authority':
? Enter value for 'clientId':
? Remember these values for later? Y/n

and if no:

? Remember these values for later? n
? Select any values to be saved (press Enter to skip)
- [ ] authority
- [ ] clientId

Not sure how I think about this experience at this moment, but it was the best I could come up with right now.

[ellismg]

If this is the case, perhaps having the ability to annotate the parameters could help with the overall experience.

There is some similar prior art in the aspire manifest itself, some parameters can be marked with generation info which tells azd and other tools: "instead of prompting here, generate a value based on this info and then save it and reuse it for subsequent deployments".