Proposal: schema for resources managed by the deploymentStack

bmoore-msft commented 2 years ago

We're looking into some api/schema changes and wanted to get some feedback. The JSON snippet below is the resources array on a deploymentStack. There are a handful of "states" or reasons why the resource is there and the idea is that we make it simple enough to identify the reason why each resource is there. The high level goal is to identify resources that did not reach the goal state and may need some manual intervention or awareness. The simple "solution" is this:

if a resource status == "managed" then that resource's goal state is for it to be part of the stack
if a resource status != "managed" then that resource's goal state is to be removed from the stack but something is preventing that and the stack will continue to try to resolve it

It's not always that simple, but that's the idea. Here's the schema, let me know if you have any thoughts - or just your reaction.

"resources": [
        {   // reached goal state 
            "status": "Managed",
            "denySettings": "denyDelete", // none, notSupported, inApplicable, denyWrite are other options
            "id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Sql/servers/sql-u6q6czz24nigq/..."
        },
        {   // could not apply deny the denyAssignment for some reason
            "status": "Managed",
            "denySettings": "denyWrite", // current state of deny from the previous deployment (if any), could be any state and different than what was requsted
            "id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Sql/servers/sql-u6q6czz24nigq/firewallRules/..."
        },
        {   // resource from a previous deployment and the current deployment failed, we assert it should be managed since we don't know otherwise
            "status": "Managed",
            "denySettings": "denyDelete", // current state of deny from the previous deployment, could be any state
            "id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Sql/servers/sql-u6q6czz24nigq/databases/...s"
        },
        {   // failed to remove denyAssignment
            "status": "denyRemovalFailed",
            "denySettings": "denyDelete",
            "id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Web/serverfarms/shared-app-service"
        },
        {   // failed to delete the resource
            "status": "deleteFailed",
            "denySettings": "none",  // denyAssignment was removed but delete failed
            "id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Web/sites/admin-3xzq5emu6gdx6"
        },
        {   // exists in another stack (theoretical state)
            "status": "ResourceExistsInAnotherStack",
            "denySettings": "none", // this stack would apply no denyAssignments since it's in another stack
            "id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Web/sites/admin-3xzq5emu6gdx6"
        }
    ]

re: the last one - resource in another stack, we're still working through how we might be able to handle that - so that one is more illustrative until we nail that down.

slavizh commented 2 years ago

looks ok to me. In case there will be some future scenarios for other status it is easy to extend with another status code.

bmoore-msft commented 2 years ago

Seems to have stuck - so going to close this one out.

Azure / deployment-stacks

Proposal: schema for resources managed by the deploymentStack #58