Closed vhvb1989 closed 2 weeks ago
With this metadata, azd makes a copy of the defaultValue (or the value if overriden with one ENV VAR) and persists it into the azd configuration. This allows azd to find the value for the parameter if it is needed during deployment as an Argument.
Must we persist the value in the config like this? Naively it feels to me that we could fetch it from the manifest or something when we needed it.
I think this is an okay solution to this problem - but I'm still trying to wrap my head around the full scope of things and how it interacts with where we are moving long term. I'm not 100% sure exactly how this all hangs together when the thing that references the value is a project.v1
and brings its own IaC. Do we expect in that world that this thing would be a parameter on the module for the container app and everything would have "just worked" as before?
This feels like a place where our strategy of "push all prompting for all values across all deployments for the app into the main.bicep
at the root" might be leading us astray. Maybe long term we need to attack that problem as well?
I'm not sure if I love neededForDeploy
as a type here, but I guess I also don't love 'generate' as the type
here - so maybe it's not the end of the world. I do think it would be nice if the type information and the generation/wiring information were separate pieces of metadata.
With this metadata, azd makes a copy of the defaultValue (or the value if overriden with one ENV VAR) and persists it into the azd configuration. This allows azd to find the value for the parameter if it is needed during deployment as an Argument.
Must we persist the value in the config like this? Naively it feels to me that we could fetch it from the manifest or something when we needed it.
I think this is an okay solution to this problem - but I'm still trying to wrap my head around the full scope of things and how it interacts with where we are moving long term. I'm not 100% sure exactly how this all hangs together when the thing that references the value is a
project.v1
and brings its own IaC. Do we expect in that world that this thing would be a parameter on the module for the container app and everything would have "just worked" as before?This feels like a place where our strategy of "push all prompting for all values across all deployments for the app into the
main.bicep
at the root" might be leading us astray. Maybe long term we need to attack that problem as well?I'm not sure if I love
neededForDeploy
as a type here, but I guess I also don't love 'generate' as thetype
here - so maybe it's not the end of the world. I do think it would be nice if the type information and the generation/wiring information were separate pieces of metadata.
I did consider adding a new way for azd to search for parameters (when need it), but that would lead us into having 2 ways of looking for params:
1) Those parames which azd needs to prompt for. Currently persisted in azd.config.json. Currently supporting secured and non-secured params.
2) Parameters defined in AppHost with a default-value. We could try to detect if those parameters are required or not as inputs to other bicep modules and if not, skip adding them in main.bicep
. Then make azd deploy
to find its value from the manifest, probably after trying to search for it in azd.config.json
anyway, as there's no way to know, during deploy, if a parameter has a defaultValue or not (unless we start deploy
by pulling all the parameters from the manifest to see how to get its value).
I think adding 2) increases the complexity v/s using the same pattern we are currently using.
The only thing I had to make in this PR is to tell azd when to persist the values, as we don't want to persist everything in azd.config.json by default.
Another NOTE: To get a parameter value defined with DefaultValue in the AppHost, we don't ONLY need to read the default value from the Manifest. We also need to check if the value is not overridden by the user using an ENV VAR. AZD is currently handling this with 1). A Parameter foo
can have a default value bar
in the manifest but folks can set AZURE_FOO=non-bar
in system env (or azd env). We would need to duplicate the logic in the approach 2)
May elevate using
sudo
on some platforms and configurations
bash:
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524/uninstall-azd.sh | bash;
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524/install-azd.sh | bash -s -- --base-url https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524 --version '' --verbose --skip-verify
pwsh:
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524/uninstall-azd.ps1' -OutFile uninstall-azd.ps1; ./uninstall-azd.ps1
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524/install-azd.ps1' -OutFile install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524' -Version '' -SkipVerify -Verbose
PowerShell install
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524/uninstall-azd.ps1' > uninstall-azd.ps1; ./uninstall-azd.ps1;"
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524/install-azd.ps1' > install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524' -Version '' -SkipVerify -Verbose;"
MSI install
powershell -c "irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4524/azd-windows-amd64.msi' -OutFile azd-windows-amd64.msi; msiexec /i azd-windows-amd64.msi /qn"
fix: https://github.com/Azure/azure-dev/issues/4523
This PR adds a new azd metadata type
NeedForDeploy
which is automatically set to bicep input parameters using a default value in the AppHost.With this metadata, azd makes a copy of the defaultValue (or the value if overriden with one ENV VAR) and persists it into the azd configuration. This allows azd to find the value for the parameter if it is needed during deployment as an Argument.