Juju azure cloud provider does not handle pre-defined Azure ResourceGroups (RG)

[Calvin Hartwell]

Hi all,

We have the requirement to use pre-defined ResourceGroups (RG) on Azure as it is against the security policy of the customer to allow them to create new ones on the fly.

To test the setup, try the following:

1. Create ServicePrincipal on Azure which does not have the permissions to create ResourceGroups
2. Attempt to bootstrap controller on Azure, you will see a failure like this:

ERROR failed to bootstrap model: creating controller resource group: creating resource group: resources.GroupsClient#CreateOrUpdate: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '<REMOVED>' with object id '<REMOVED>' does not have authorization to perform action 'Microsoft.Resources/subscriptions/resourcegroups/write' over scope '/subscriptions/<REMOVED>/resourcegroups/juju-controller-model-<REMOVED>' or the scope is invalid. If access was recently granted, please refresh your credentials."

We need a config or constraint to allow resources to be created in a specific resource group as opposed to having Juju create its own.

Cheers,

- Calvin

[Pen Gale (pengale)]

Marking as wishlist for now, as this is a feature request.

Happy to bump this up in priority (possibly bumping current roadmap work) if need be.

[Ian Booth (wallyworld)]

This would need to be done on a per model basis, ie each model would need to be configured to use a different resource group. This is because "machine-0" can exist in many models and each model's entities need to be kept separate from each other.

So for each model, you'd need to:
1. create a resource group via the azure dashboard or cli
2. juju add-model foo
3. juju model-config resource-group-name=foobar
4. juju deploy....

[Ian Booth (wallyworld)]

juju destroy-model needs to be changed so that instead of removing the resource group corresponding to the model, we purge the contents. This removes any machines, networks, etc that had been created in the model but leaves the resource group itself. That works fine. However...

There's an issue with destroy-controller. At destroy time, we have the controller-uuid. What is done now is we find all of the resource groups with that tag and destroy the content of those resource groups, ie clean up all the models of the controller.

But, if an existing resource group is used, there's no Juju tags added and the current mechanism of doing a bulk query for all relevant resource groups to clean up can't work. And there's no easy way around it - we don't have access to the models to know any bespoke resource groups when destroying is done and changing that is impractical, not least because it's provider specific and only relevant to Azure.

So the only current workaround would be to ensure destroy-model is called on any models using existing resource groups before running juju destroy-controller. Or you will need to manually purge those resource groups later.

[Ian Booth (wallyworld)]

To bootstrap using a resource group called juju-test

juju bootstrap azure -config resource-group-name=juju-test --no-default-model

[Ian Booth (wallyworld)]

https://github.com/juju/juju/pull/11821

Note the known issue - destroy-controller cannot see any resource groups not tagged with the controller uuid. So before juju destroy-controller, you will need to juju destroy-model any models using a pre-definedresource group.

[Ian Booth (wallyworld)]

This is now in the 2.8 edge snap (version 2.8.2).

Note the limitations:
- each model must have a different resource group configured (if used); you can't mix machines etc from different models in the same pre-defined resource group
- if using resource-group-name, you must bootstrap with --no-default-model since otherwise the controller and default models would share a resource group
- when destroying a controller, you must delete the contents of any pre-defined resources groups manually (juju needs significant changes to access the necessary model config at time time of destroying a controller to do it automatically)