Document DomainService deletion behavior regarding user-created resources

[maximiliantech]

Problem

When a user deletes a ServiceProviderAPI object (e.g., Flux) at the onboarding cluster, the ServiceProvider begins tearing down its managed resources (HelmRelease, OCIRepository, Secrets - all these resources so that a domain service runs). However, there's no check to verify whether user-created resources of that domain's APIs (e.g., GitRepository, Bucket, HelmRepository) still exist on the MCP.

This can lead to:

• Orphaned custom resources on the MCP after the controllers are removed
• Unexpected behavior for end users who still have active resources

Proposed Documentation

Add a section to the Service Provider development guide that:

1. Makes developers aware when proper finalizer handling is critical
2. Explains the expected deletion flow (check for user CRs before removing managed resources)
3. Explain the problem of determining which objects block deletion (generically) but in the same time it would be desirable to give the end user a good UX e.g. by adding a new status condition/phase (DeletionBlocked) to the ServiceProviderAPI object at the Onboarding cluster
4. Notes that this protection mechanism is not yet implemented in the service-provider-runtime/template

Acceptance Criteria

• Section added to service provider development guide documenting this behavior
• Follow-up issue created in service-provider-template describing how this should be implemented (e.g. commented code block outlining the point in reconciliation where deletion prevention should get checked)

[christophrj]

Describes this limitation

I wouldn't describe this as a limitation of the guide or template but we need to make developers aware when this is critical, e.g. if a DomainService controller doesn't properly set finalizers to its CRs to prevent deletion of the CRD as long as objects exist.

[maximiliantech]

Describes this limitation

I wouldn't describe this as a limitation of the guide or template but we need to make developers aware when this is critical, e.g. if a DomainService controller doesn't properly set finalizers to its CRs to prevent deletion of the CRD as long as objects exist.

Thanks for the feedback @christophrj. I have updated the issue description above. Does this fit your expectation?

[christophrj]

The limitation is that there is probably no good way to tell the user which objects block the deletion of the managed service in the onboarding object status. And the 2nd limitation is that we don't offer a force delete for the same reason.

[maximiliantech]

Issue description updated with @christophrj