Shared/Central parameters support

[Jefajers]

This issue is a split from #831

Ability to associate/import/refence multiple parameter files into one outcome.

A fair amount of parameters will be shared by customers as well, which could lead to duplication among the parameter files. However, the Bicep community is already working on parameter imports in Azure/bicep#12019.

[schaijkw]

A cascading style will be nice. So you can inherit from a more general bicepparameter file and still have the ability to overrule an imported parameter. Like the union() function currently works. The last written value survives.

[Xitric]

Hello @Jefajers,

Extendable parameter files became available as a preview feature in Bicep some time ago. I wonder if we should begin discussing how AzOps could support this new Bicep feature?

For reference on my thoughts, we are using these AzOps settings:

"AzOps": {
  "Core.AllowMultipleTemplateParameterFiles": true,
  "Core.DeployAllMultipleTemplateParameterFiles": true,
  "Core.ParallelDeployMultipleTemplateParameterFiles": true,
  "Core.MultipleTemplateParameterFileSuffix": ".\\w+"
}

Some thoughts on my end:

1. If I try to use extendable parameter files today, AzOps attempts to locate a template file to associate with my generic parameter files, hence failing the deployment. Example:

   customer.bicep
   customer.one.bicepparam
   customer.two.bicepparam
   westeurope.01.bicepparam
   

   Where customer.one.bicepparam and customer.two.bicepparam both extend from westeurope.01.bicepparam as such:

   using 'customer.bicep'
   extends 'westeurope.01.bicepparam'
   
   param ...

   This fails, rather expectedly, with:

   Did NOT find template for parameters root/mg (00000000-0000-0000-0000-000000000000)/sub (00000000-0000-0000-0000-000000000000)/westeurope.01.bicepparam

2. Currently, the association between bicepparam files and template files is based on naming of the files as well as the configuration Core.MultipleTemplateParameterFileSuffix. However, bicepparam files have a using statement that defines the association to the template. Perhaps it would be possible to utilize that instead? Then it would also support generic bicepparam files out of the box, since they specify using none, and hence they shouldn't be deployed.

   • In extension to this point, perhaps a first step could be to not locate template files for bicepparam files with using none.

3. And then onto the more complex stuff. Let's say that I have a number of bicepparam files, that extend each other in a chain:

   // westeurope.bicepparam
   using none
   param location = 'westeurope'
   ...

   // westeurope.01.bicepparam
   using none
   extends 'westeurope.bicepparam'
   param instance = '01'
   ...

   // customer.one.bicepparam
   using 'customer.bicep'
   extends 'westeurope.01.bicepparam'
   param customerName = 'azops'
   ...

   If I were to make a change to westeurope.bicepparam, I would actually expect AzOps to redeploy the customer.bicep template for every customer.x.bicepparam file that extends (transitively) from westeurope.bicepparam.

   We could probably accept a solution that requires all bicepparam files and templates to be in the same directory, but a solution that is capable of letting bicepparam files extend from files in parent directories would be optimal. Extending from bicepparam files in sibling directories seems like a mistake in my opinion, which could lead to unexpected behaviour.

I have also heard talk from the Bicep community about a proposal for a special type of "deployment file" that can specify things like what template to deploy, which parameter file(s) to use, settings for deployment stacks, etc. Right before the community call next week, my team is going to have a chat with some of the Bicep maintainers about bicepparam files, so perhaps we can find some synergies between Bicep and AzOps as part of that.

[Jefajers]

@Xitric, lets sync up after your meetup with Bicep maintainers 👍 and take it from there as we aim to incorporate usage of Bicep features together with AzOps.