meshcloud/unipipe-service-broker

RFC: unipipe gc command

Opened this issue · 0 comments

One challenge with growing service instance repositories is that service instances and their associated desired state (bindings etc.) accumulate. In order to allow CI/CD pipelines to handle deletion properly, unipipe-service-broker uses soft-deletion and sets a deleted: true flag in the instance/binding yml files.

unipipe-cli already offers handy ways to filter for deleted instances. However, after an instance was successfully deleted by the CI/CD pipeline (using an async OSB API operation), the data remains in the git repository. This clutters it up and makes it more difficult to navigate.

A unipipe gc (gc for garbage collection) run could clean up "expired" (tbd what exactly that means) service data from the git repository and therefore keep it lean. In case we decide to do this we must carefully think about edge cases around marketplaces polling deleted service instance states. This also involves checking the behavior is possible with unipipe-service-broker and common marketplace implementations. Some quotes from the OSB API spec

Note that a re-sent DELETE request MUST return a 202 Accepted, not a 200 OK, if the unbinding request has not completed yet.

(410 GONE) MUST be returned if the Service Binding does not exist.