[.NET] <module>.parameters.json would be nice to have back

[bradygaster]

A few of the investments we're thinking of making on the .NET side would lend themselves very-very well to having support for individual module parameter JSON files added back in. Take a complex app with 5 container apps in it, for example, but with only 2-3 variations per app in terms of their settings or environment variables. If customers could have the JSON approach to editing these settings and having single-project capabilities for editing variables, it could be a lot less daunting for developers who don't-yet-know Bicep but want to take advantage of it.

CC @jongio, with whom I met today on this, as he'll have more context for the team.

[savannahostrowski]

Was also chatting with @bradygaster today about some of these scenarios. @rajeshkamal5050 would be good to prioritize smoothing this out next iteration.

[bradygaster]

Thanks @savannahostrowski - @rajeshkamal5050 we essentially have some plans we're trying to shore up for November, and one of the things we want to invest in is a tighter integration option between .NET and AZD, and if it's possible that we could get these JSON files back in, or, be updated on how individual modules can be parameterized via JSON, it'd be super-helpful as we're creating click-throughs and mock-ups.

[ellismg]

I do wonder how much of this you could build outside of azd today. Bicep already has a loadJsonContent feature that allows you to load and use a JSON document as part of your template. It seems like you could use that to get most of the way to what you want, without having to involve azd at all.

azd does allow you to do replacements, based on values in the environment, in our .parameters.json files (as well as some other intrinsics, like looking up a secret from KeyVault or generating a new one if it didn't exist), and you wouldn't be able to leverage that with the above approach, because this whole scheme would be transparent to azd. I could imagine some hacks there (like using a pre-provisioning hook to modify the .prameters.json files) but that's definitely a place where doing some azd specific work could yield improvements.

[bradygaster]

I specifically tried using <modulename>.parameters.json to no avail. It seems as if the per-module parms files was recently deprecated or something. Apologies if I'm using it wrong [open to feedback/guidance].

[ellismg]

I specifically tried using .parameters.json to no avail. It seems as if the per-module parms files was recently deprecated or something. Apologies if I'm using it wrong [open to feedback/guidance].

IIRC, We only ever supported using a .parameters.json for the top level template (i.e. main.parameters.json corresponding to main.bicep).

What I envisioned is doing something more in the template itself, as you could do with any bicep template.

Azure-Samples/todo-nodejs-mongo@main...ellismg:todo-nodejs-mongo:ellismg/use-json-file-with-modules

Has a little sketch of what I was thinking you could do today, with the released version of azd by just using the loadJsonContent feature in bicep to read api.settings.json (you can name this file whatever you want, I used .settings.json instead of .parameters.json to make it clear it need not be an ARM Template Parameters file) and then use that value if it is set.

This file can only contain fixed strings, not replacements like ${AZURE_ENV_NAME}, but I wonder how far you can with that today.

[jongio]

Let's get @wbreza input as he implemented the module.parameters.json initially and then recently removed it. He'll have more insight.

[bradygaster]

This file can only contain fixed strings, not replacements like ${AZURE_ENV_NAME},

That's unfortunate and would mitigate me wanting to try that route. I'd be giving up the ability to read environment variables generated by main.bicep and the provisioning process. That's one of the key features of AZD I'd want.

[ellismg]

Let's get @wbreza input as he implemented the module.parameters.json initially and then recently removed it. He'll have more insight.

Ahh - this makes me better understand what the request was here. This support was only for container apps and was tied to how we did Azure Container App deployments when we first added the feature. In that world, deploy for an ACA app would end up doing a bicep deployment to deploy a module that represented just the service itself.

Since this was a top level deployment, we were able to use api.parameters.json to control the parameters that were passed to the the api.bicep module. Changed to this api.parameters.json file were not used however for the initial azd provision, only on azd deploy.

Initially I thought this was about using a parameters file to control the parameters for any arbitrary module used from the root deployment. I see now that this is perhaps specific to ACA.

We removed the api.parameters.json support because we shifted to a world where deploy for container apps meant "just go update the image ID on the existing resource" and once we did that there was no longer an ARM deployment to configure.

Somewhat related to this was the work we were thinking about with container apps to use a yaml based file to explain the deployment instead of doing all this stuff in bicep. I had sketched out what that might mean here. In this world, instead of authoring bicep for each container app you want to deploy, you'd instead write a yaml file that describes your app, similar to a k8s manifest and then azd would do replacements in that yaml template and push it to the container apps control plane to have the app created. It may be more palatable to edit this file vs a bicep template, and the fact that we had separate ones per container app could be helpful. There are probably many properties of this yaml we could have azd default if the are not set before it is pushed to the control plane, so things could be even simpler.

[rajeshkamal5050]

@bradygaster closing this one. Given the integrations happening on the .NET side which is tracked here - https://github.com/Azure/azure-dev-pr/issues/1579