Resource Cleanup on delete #90
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
Should we set |
|
Quick question (I might be jumping ahead since I vaguely remember you mentioning that there will be multiple PRs for source cleanups): If I set |
Only once we have implemented handlers for them |
It's per service. Since change router is a universal service across all sources, if we implemented a handler, it wouldn't need a special config, so we could to call it if we wanted to. |
|
I think, in future, we should do separate PRs for things like the changes to the shared infrastructure abstractions. |
danielgerlag
force-pushed
the
resource-gc
branch
from
ec64b98 to
c176422
Compare
* main: Resource Cleanup on delete (drasi-project#90)
Description
This PR adds infrastructure to clean up resources when sources / reactions are deleted. It takes a 2 pronged approach.
The first is to add an optional
deprovisionHandlerto any resource service. This is defined on the Source / Reaction Provider spec. When the resource is deleted, the control plane will do a best effort attempt to call the deprovision method on the service, using standard Dapr retry semantics. If the handler is not callable, to resource will still be deleted.To second, is to include an
INSTANCE_IDenvironment variable on each service. This value remains the same for the lifetime of the resource (source/reaction). If you delete and recreate the resource with the same name, the instance id will change. Thus the service can inspect if the instance id is as expected, if not then any existing state should be considered stale.Both mechanisms have been implemented for the debezium reactivator.