Allow Existing Resource Groups with Azure Policies to be Used

[rogueautomation]

Version:

kitchen-azurerm-1.8.0

Environment:

10.0.19044

Scenario:

When issuing a kitchen create using an explicit resource group name, if the resource group already exists the driver still attempts to create the group. This can run into organizational guardrails such as azure policy that are in place at the resource group level, and can remove configurations, including tags from an existing resource group.

Steps to Reproduce:

Create a resource group - apply configurations such as tags
Issue a kitchen create, specifying that resource group name as an explicit resource group name attribute

Expected Result:

We would expect the resource group would not change, as it already exists and should not be built

Actual Result:

The resource group is modified to match only what is specified in the kitchen yaml - removing configuration values such as tags, and if values are missing that are required by azure policy the create action will fail.

Additional Comments

Looking at the driver, I would think that before issuing the RG create - if a check were to validate whether or not a group existed, and if it did then skip the RG create would be enough to resolve this similar to the logic at https://github.com/test-kitchen/kitchen-azurerm/blob/master/lib/kitchen/driver/azurerm.rb#L814 - or - including a 'skip rg creation' parameter would allow existing resource groups that are managed outside of CHEF for organizational controls to be used.

[sanjain-progress]

Right now there is no provision to define Resource Groups policy explicitly. Test-Kitchen picking up the value from platforms -> name and append the current timestamp. So every time the kitchen create command executes it always create new Resource Groups policy with unique name.

I also check from Azure app, even the app doesn't provide to creation of Resource Groups policy with same name.

Are you looking for a way to define Resource Groups policy explicitly?

[sanjain-progress]

In addition to that

Giving support to use existing Resource Groups policy affect the existing flow. Whatever the resource create by kitchen create command also get destroy at the time of kitchen destroy kitchen test. And it gets tricky to keep track of what resources are created at the time of kitchen create if .yml file changed.

[rogueautomation]

Hey @sanjain-progress - We're simply looking to use existing resource groups without attempting any modification of the existing resource group.

[KenzoB73]

Hey @sanjain-progress - We're simply looking to use existing resource groups without attempting any modification of the existing resource group.

Agree, all we want to do is create and delete a VM in Azure, there should be no need to touch a resource group at all if it already exists. Create the vm and required disks/nics in the resource group, when kitchen destroy is run, then delete the VM and associated disks/nics. Can't believe this is stagnant since 2022.