gberche-orange
commented
4 years ago What about annotating provisionned backing services and apps with the brokered service instance guid (and potentially other metadata such as a config version/hash), in CF meta-data ?
Then the algorithm for brokered service delete, is to lookup any backing app/service with the associated metadata, and delete them.
See related conversation at https://github.com/spring-cloud/spring-cloud-app-broker/issues/344#issuecomment-600611289 and related work at https://github.com/orange-cloudfoundry/osb-cmdb-spike/issues/10
Problem Currently app broker supports creating backing app with existing backing services (see
CreateInstanceWithExistingServicesComponentTest). If the backing service exists before the backing app bind to it, then it’s risky to just delete it when we delete the backing app. For example, a shared database instance or a user provided service.Proposed solution If the backing service details (e.g. plan) is specified in the configuration, we can assume broker developers rely on app broker to manage the backing services, so we delete the backing services when no longer needed. If the backing service details is not specified, or the bound service is not listed in the configuration, then we only need to unbind the service but not delete it.
What's not covered by the proposed solution When there is an update in the backing service list, the existing backing service may become an unknown backing service if we do an
upgradeupdate. So the proposed solution would just unbind it but not deleting the existing backing service. But the risk of this is not too high because when we eventually delete the space, it will be deleted cascadingly. If this gets more risky and needs attention, it's also worth exploring to leverage CAPI version metadata.