STOP the non-sense of making Resource Groups for these services if you really want us to use them!! Completely annoying.
Totally insane. Databricks is the WORST offender of this, but Network Watcher does it as well. I won't allow RGs to be created unless they are NAMED and TAGGED according to OUR rules, so people cannot use this service. Period.
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote & comment on. This allows us to effectively prioritize your request against our existing feature backlog and also gives us insight into the potential impact of implementing the suggested feature.
Morten Henrichsen commented
It is particular annoying that the recommended naming convention for resource groups is to prepend "rg-" to the name. The managed resource group then use that name to create its name, which then becomes something "databricks-rg-rg-myresourcegroup".
You could at least follow your own best practice for naming the resources, so the managed resource group would be "rg-databricks-rg-myresourcegroup"
Pope, Jeffrey T. (IT) commented
Agree. Databricks, AKS and Synapse fall into this category. In addition, once the RG is created for databricks and Synapse you cannot add tags as it denies it. I know some of this can be done via ARM but it needs the option in the portal as well,
Moore, James commented
Can you please allow us to change the storage account name too? Microsoft.DataBricks/workspaces/parameters.storageAccountName does not work :(
Andrew Sears commented
AKS also creates a separate managed user group. It would be great if it could inherit tags and allow naming template.
Paul Ruler commented
Hello @Ron Bokleman,
We have faced a similar issue when deploying Databricks into subscriptions tightly controlled by both resource group and resource naming policies that simply restricted the dynamic creation of the required Databricks resource groups and resources.
If you are using the portal then you have no control over the resource group name it automatically creates, but if you deploy via an ARM template (which is what we do) you can take control and enforce the Databricks automatically created resource group to take on the name of your choosing by modifying the WorkspaceProperties/managedResourceGroupId value. This won't apply to the resources it creates inside that group by default and when clusters are running, I haven't found a way of controlling those names. We needed to get the customer to introduce exclusions for the dynamic resource creation within these now name controlled resource groups which has worked well so far.
Example of our extract, our variable is simply a concat string to build up the Resource ID of this resource group to be created: -
By including a tags section to the Microsoft.Databricks/workspaces to the resource you are provisioning, this automatic group will also apply the tag values you have specified and these also apply to the 3 default resources it creates inside this group – 1 x storage account, 1 x NSG, 1 x VNet along with its own system tag values. Again, you can only do this via an ARM template.
I take your point about the automatic creation of resource groups without being able to control the names of those and that is a valid issue for Azure to work through, but I hope this helps you particularly with Databricks instance provisioning.