search

Azure / bicep-registry-modules

Bicep registry modules
MIT License
466 stars 311 forks source link

[AVM Module Issue]: Support multi-scope modules (e.g., budget, role assignments, etc.) #859

Open AlexanderSehr opened 7 months ago

AlexanderSehr commented 7 months ago

From the comments below:

Update the CI to support: --scope-<scope> suffix for modules

Examples

Note: This likely requires changes in all places where we extract the providernamespace and resource-type from the folder path (which is ideally done by a central function). For example, in the readme generation, the publishing, the location rotation logic, etc.

Quoting original issue:

'Microsoft.Consumption/budgets@2021-10-01' should be able to support the creation of a budget on a resource group. Currently, it only allows the scope of subscription().

github-actions[bot] commented 7 months ago

@AlexanderSehr, thanks for submitting this issue for the avm/res/consumption/budget module!

A member of the @azure/avm-res-consumption-budget-module-owners-bicep or @azure/avm-res-consumption-budget-module-contributors-bicep team will review it soon!

segraef commented 7 months ago

Will have a look at it once I can.

AlexanderSehr commented 7 months ago

@segraef please note we create a user story to implement a solutino that will include a naming pattern spec that allows us to create modules on multiple scopes (e.g. consumption/budget--rg & consumption/budget--sub or something like that. For it, we need to agree on the convention + update the CI to be able to handle it.

AlexanderSehr commented 6 months ago

To whom it may concern a quick update that we created a work item to enable multi-scope modules / define a convention for it. This will require a CI update so it will take some time to implement.

AlexanderSehr commented 2 weeks ago

Sidenote: This will also have an effect on the 'Microsoft.Authorization' namespace as its resource providers usually deploy to at least 2 scopes (e.g., role assignments)

cc: @arnoldna

AlexanderSehr commented 2 weeks ago

We still need suggestions on the convention. For example

--<scope> suffix

--scp_<scope> suffix

--scope-<scope> suffix

It's important to keep in mind that the convention will not only need to stand the test of time, but that it's also directly impacting the published resource's name.

arnoldna commented 2 weeks ago

We still need suggestions on the convention. For example

--<scope> suffix

  • consumption/budget--rg (may conflict with web/sites/config* modules)
  • consumption/budget--sub (may conflict with web/sites/config* modules)
  • consumption/budget-mg (may conflict with web/sites/config* modules)

--s_<scope> suffix

  • consumption/budget-s_rg
  • consumption/budget-s_sub
  • consumption/budget-s_mg

--scoped-<scope> suffix

  • consumption/budget--scoped-rg
  • consumption/budget--scoped-sub
  • consumption/budget--scoped-mg

It's important to keep in mind that the convention will not only need to stand the test of time, but that it's also directly impacting the published resource's name.

I wonder if we will have any other issues related to using a "--".

AlexanderSehr commented 2 weeks ago

Not right no, no. The web/config modules already use that syntax, be it not to differentiate the scope, but variantes. And the readme generation is smart enough to cut that part out when generating the readmes. But it's the reason we'd likely need something else. But we should test it first, of course (i.e., use a fork, implement a module that would be published, run the utilities and try to pushlish it into a private registry). If it 'happens' to work, then we'd save ourserves a lot of work 😄

AlexanderSehr commented 2 weeks ago

Alright, it likely we'll be going with this option:

--scope-<scope> suffix Examples consumption/budget--scope-rg consumption/budget--scope-sub consumption/budget--scope-mg

Now it's just a matter of planning it in after the current set of CI changes and get the ball rolling. It 'should' not take too much effort to implement, but testing will take some effort.