You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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 destroykitchen test. And it gets tricky to keep track of what resources are created at the time of kitchen create if .yml file changed.
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.
The text was updated successfully, but these errors were encountered: