Repository navigation
[Bug Report]: resources/resource-group - ResourceGroupManagedByMismatch #3386
Description
Describe the bug
Azure defaults ResourceGroup.managedBy as null but the ResourceModule template defaults to empty string. It is also not possible to set null with this module.
If I check if empty and send null then I get another error:
InvalidTemplate - Long running operation failed with status 'Failed'.
| Additional Info:'Deployment template validation failed: 'The template
| resource 'RG-Workday' at line '1' and column '2529' is not valid:
| Evaluation result of language expression
| '[if(empty(parameters('managedBy')), null(), parameters('managedBy'))]'
| is type 'Null', expected type is 'String'.. Please see
| https://aka.ms/arm-functions for usage details.'.To reproduce
- Create a resource group through azure portal
- Create bicep for this resource group
module ResourceGroup '.carml/resources/resource-groups/main.bicep' = {
name: '${deployment().name}-ResourceGroup'
params: {
name: resourceGroupName
location: resourceGroupLocation
}
}- Deploy Bicep
The managed by property of the resource group cannot be changed from its current value '<null>'
Code snippet
No response
Relevant log output
{
"code": "DeploymentFailed",
"target": "/subscriptions/***",
"message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
"details": [
{
"code": "ResourceGroupManagedByMismatch",
"message": "The managed by property of the resource group cannot be changed from its current value '<null>'."
}
]
}Reacted by Khalid Dermoumi
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
zydio commentedon Jul 25, 2023
This also happens to any Resource Group deployed using CARML modules with v <= 0.8.0, when trying to deploy again the same BICEP with CARML v >= 0.9.0: the deployment will fail.
The PR that introduced the
managedByparameter is #2319 which was also erroneously marked as non-breaking change.. but as stated this breaks any existing deployment.adnkai commentedon Aug 29, 2023
Any news on this?
coolhome commentedon Sep 11, 2023
I wonder if we should report this as a Resource Provider bug because I think the value should always be an immutable string. Alternatively, maybe there should be a ManagedResourceGroup module that separates this functionality out.
If you consume this module, I suggest removing the managedBy param.
zydio commentedon Sep 12, 2023
I believe anyone using the module has been removing the
managedByparam but this is a (painful) temporary workaround because it forces us to not use the stock modules: a proper fix should be available in CARML.Potential workaround for Azure#3386
AlexanderSehr commentedon Dec 10, 2023
While I recallr reading the original issue, I didn't get around looking deeper into this. Sorry everybody, and thanks Preston Alvarado (@coolhome) to give it a shot. I just notified the module owner to take a look so that it's also included in AVM, and further commented on the PR. I'd hope that
nullablehelps us out.russellds commentedon May 29, 2024
Anyone know of a way to fix this without redeploying the Resource Group? I have a bunch of Resource Groups that have this issue.
AlexanderSehr commentedon Jun 1, 2024
That's a tough one. From the top of my head it would only come to mind to deploy 'new' resource groups and migrate all existing resources to those resource groups. :-/
AengusMo commentedon Jun 6, 2024
Similar to Russell Slater (@russellds) ... in our case we updated core RG's some time ago and we have now discovered this issue, recreate is not an option so I assume it's now a 'live with it' or can Msft do anything on the backend?
AlexanderSehr commentedon Jun 6, 2024
Hey AengusMo, for that I'd ask you to open a support ticket, as we don't have access to the backend - yet alone a customer's backend. :-/