Sharing resources: a claims pattern for Compound Promises
If you have been writing Compound Promises, you have probably wondered: what happens when multiple resources need to share one unique resource provided by a sub-Promise?
For example, imagine an Application Promise that deploys applications on Kubernetes. Each application may need a namespace on the destination cluster, so you make it a Compound Promise and use the Namespace Promise from the Marketplace. You know the drill: the Application Promise's configure pipeline writes the Namespace request to /kratix/output/, Kratix schedules it to the Platform cluster, and the Namespace Promise does its thing.
You request your first application, app-one, in the team-mobile namespace. The pipelines run, you see the Namespace request come through, the namespace appears on the destination, shortly followed by the application. So far, so good. You now want to deploy a second application, app-two, also in team-mobile. You send the request, the pipeline runs, and... nothing happens.
You check your GitOps agent logs and see that you now have two requests for the same Namespace. It does not like that. You update your Promise pipeline to only emit the Namespace request if it does not exist yet. Everything seems to work, until you delete app-one, the original requester of the Namespace. As the Namespace request is owned by app-one, it gets deleted. app-two, deployed in that namespace, gets wiped out in the process. Absolute chaos.
Congratulations: you have discovered that work ownership and shared resources are not friends.
In this post we walk through a Promise design that fixes this. We call it claims, and there is a working example in the Marketplace.
