You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 specThe text was updated successfully, but these errors were encountered: