Abstractions between CloudFormation templates and resource registry

[benkehoe]

Some context from @rjlohan:

Right now the Registry only supports the ability to (De)RegisterType, however we designed it intentionally to be as agnostic of CloudFormation (the service) as we could. Certainly there will be abstraction leaks, but we intend to separate concerns so that we have the ability to cleanly build out other capabilities in the future.

The Resource platform does not know anything about CloudFormation's stack-level concerns. (To be fair a couple of things leaked through, but again the intent was to design the Registry and the resource platform to be completely oblivious to CloudFormation the service.

I get the separation between stack-level concerns and resources. And I get that the registry should model all resources, not just AWS service resources. But there are semantics in CloudFormation templates that seem useful to model in resources.

For example, I expect that when I delete a stack, the resources owned by the stack should also be deleted, unless I put a DeletionPolicy: Retain on them. If a resource is by design leaving things behind when the update or delete handler is called, I feel that should be surfaced to the user through the template in some way, because that's unexpected behavior. One way to do this would be for a resource to indicate it does this, and for CloudFormation to require DeletionPolicy: Retain for those resources.

[rjlohan]

So the way I think about this particular dimension is this; a Stack is a set of Resources. When we create a stack, we are really creating a set of resources. Likewise, deleting a stack is asking that the set of resources be deleted.

So... DeletionPolicy: Retain is really a concern of the Stack. With this policy we are saying; "when I delete the stack, don't delete the resources, simply remove them from this set".

As such, I don't believe DeletionPolicy, CreationPolicy, UpdatePolicy or UpdateReplacePolicy are concerns of the resource. They are instructions to the CloudFormation service itself in how it should behave when operating on the Stack.

So - a Resource Provider shouldn't care about CloudFormation's DeletePolicy. With DeletePolicy: Retain CloudFormation will simply remove the resource from the Stack, and the Delete handler will not be invoked at all.

[benkehoe]

I get that. But if the Resource Provider is leaving cruft behind, as the proposed ResourceType resource provider would (and as the Lambda version publisher does), what happens then? Shouldn't there be a mechanism that can alert users to this fact, and could a forced delete-retain serve as that mechanism?

[PatMyron]

As such, I don't believe DeletionPolicy, CreationPolicy, UpdatePolicy or UpdateReplacePolicy are concerns of the resource

think Snapshot policies for DeletionPolicy and UpdateReplacePolicy are resource type specific and should be modeled as handlers. UpdatePolicy also seems incredibly resource type specific

[benbridts]

Re: deletion

I agree with Ben, in the sense that Resource Providers should not leave things behind when a Delete is called. If the resource provider only manages one thing (as it probably should), this is also an implied part of the contract:

from the docs:

In order for a delete request to return an operation status of SUCCESS, the following must be true:

A subsequent create request MUST be able to create a new resource with the same set of properties; a subsequent create request MUST NOT fail with an error code of AlreadyExists.
[...]
A subsequent read request SHOULD return an error code of NotFound.

A subsequent list request SHOULD NOT contain the deleted resource.

---

Regarding handlers:

think Snapshot policies for DeletionPolicy and UpdateReplacePolicy are resource type specific and should be modeled as handlers. UpdatePolicy also seems incredibly resource type specific

I agree. But that should not expose the different kind of policies to the provider, the provider should not have to care why the delete is not triggered, or why a snapshot might be triggered. So, I'd expected one handler for snapshot and the CloudFormation engine deciding when to call that (probably in two steps - first the snapshot handler, then the delete handler, since they can be independent).

The UpdatePolicy is trickier, as those are far less generic.