Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: unipipe gc command #49

Open
JohannesRudolph opened this issue Jun 1, 2021 · 0 comments
Open

RFC: unipipe gc command #49

JohannesRudolph opened this issue Jun 1, 2021 · 0 comments

Comments

@JohannesRudolph
Copy link
Member

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.

@felixzieger felixzieger transferred this issue from meshcloud/unipipe-cli Oct 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant