New-AzSubscriptionDeploymentStack has parameter -ResourceGroupName

[slavizh]

Describe the bug New-AzSubscriptionDeploymentStack has parameter -ResourceGroupName. I believe that command should not have such parameter at all as you are doing subscription level deployment

To Reproduce

Expected behavior To not have such parameter

Screenshots If applicable, add screenshots to help explain your problem.

Repro Environment Host OS: Windows 11 Powershell Version: 7.3.1

Server Debugging Information Correlation ID: Tenant ID: Timestamp of issue (please include time zone): Data Center (eg, West Central US, West Europe):

Additional context Add any other context about the problem here.

[dantedallag]

The -ResourceGroupName parameter allows Subscription scoped stacks to scope their deployment to a Resource Group. If none is specified, the deployment will default to the scope of the stack (the subscription). So, there can be a difference between the scope that the stack is deployed at and the scope that the underlying deployment is at. I think it may help to add some extra documentation.

[slavizh]

You can look at the model of New-Az*Deployment cmdlets and follow that to have the same experience.

[dantedallag]

I think this parameter will differ from the New-Az*Deployment cmdlets as stacks have two layers: the stack itself and the underlying deployment. We want a way to specify the scope for both layers (with the stack always being at a higher or equal scope to the underlying deployment). I think most of the time when a user is deploying a stack at the subscription scope, they will also want the deployment to be deployed at the subscription scope, but in case they would prefer the deployment be deployed at a resource group scope, they can specify the resource group with this parameter. I don't believe the New-Az*Deployment cmdlets have anything analogous to this.

[alex-frankel]

I am wondering if the tricky part here is the mental model I have when I use a given command group. When I use az stack sub I am expecting to do a sub scoped deployment. I don't expect to even have the option to do the deployment at a resource group.

I just encountered this parameter set by accident because I had a default resource group in my az CLI config. I had to remove the configuration in order to do a "normal" sub-scoped deployment.

I am thinking about an alternative proposal for storing the stack at a higher scope. I'm not sure we have an easy way to look up the immediate parent, but it would be cool if we could do something like:

az deployment group create -f 'myRgDeployment.bicep' ... --store-at-parent

or if it's easier maybe a dedicated command

az deployment group create-at-parent --subscription '...' -f 'myRgDeployment.bicep' ...

With the current parameter set, I do worry that it might be too easy to accidentally stumble upon this capability.

[slavizh]

@dantedallag ok. Not sure what is the use case for deploying something at subscription level and put it in resource group. And what if you put it in the resource group that is part of the deployment. Wouldn't that lock the deployment stacks resource? Might be interesting to try those scenarios. At least from my perspective does not makes sense to do deployment at one level but put the stacks on another. May be there is some play of dividing the stacks with permissions on lower level like resource groups that I do not see currently.

[alex-frankel]

It's the opposite. If you use the -ResourceGroupName parameter set, then the stack will be stored at the subscription and the deployment will be scoped to the specified resource group. By doing this, a resource group owner cannot remove the stack resource to remove their deny assignments. Otherwise, the deny assignment can be somewhat easily removed if the RG owner wanted to do so.

It will be the same story for the New-AzManagementGroupDeploymentStack command -- if you set a -Subscription parameter, then the stack will live at the MG scope, and the deployment will be done at the subscription scope.

[slavizh]

@alex-frankel this is quite confusing behavior for me compared to the experience with deployments. Probably it is because we always had some ground rules to use only subscription and management group scope deployments and the resource groups creation to be always part of the subscription deployment. At least it makes it clearer now. May be I can see some cases for deploying at subscription scope and storing the stack at management group but doing resource group deployment and storing it at subscription one is exotic to me as why would you have a pre-created resource group. Anyway if there is such option it should be there may be other folks will find use of it. Definitely this needs to be documented behavior.

[alex-frankel]

FWIW, we are planning to change this parameter name to get rid of some of the initial confusion, and we will definitely document it cc @apclouds. @dantedallag can you share the new parameter name?

Admittedly, the "storing at parent scope" is more of an edge case, but one we suspect will be important for those users who need it.

[dantedallag]

We are changing the -ResourceGroupName parameter to -DeploymentResourceGroupName in the sub new and set cmdlets. This follows the naming convention used in New/Set-AzManagementGroupDeploymentStack where -DeploymentSubscriptionId sets the subscription that the management group scoped stack's deployment will be deployed into.

[azcloudfarmer]

There is a new section in the tutorial that further elaborates how to think about these parameters: https://github.com/Azure/deployment-stacks/blob/main/TUTORIAL.md#create-a-deployment-stack-with-deployment-at-a-lower-scope