Feature: Landscaper: Orphan clean-ups should respect dependencies between orphans

(This feature request is copied from the support repository)

Understand the problem

When Landscaper creates, updates or deletes (sub-)installations and deploy items, it performs these operations in an order that respects dependencies between those entities. This is really great! Many other tools don't do that very well.

However, orphan clean-ups of sub-installations and deploy items ignore dependencies altogether. Orphans clean-ups are deletions of no longer existing items executed as part of an update reconciliation.

This breaks things if dependencies are required for uninstallations. As a consequence, deletions may fail and require manual intervention which may be difficult to do, e.g. manually installing an already deleted dependency just to fix a failed installation.

Therefore, Landscaper's orphan clean-ups should execute the deletions according to the dependencies between the items.

The order of orphan clean-up deletions must be determined from the dependency graph as it was defined before the update (an update may also change dependency definitions) and consider indirect dependencies.

Example:

• Old items:

  A -> B -> C
  

• New items:

  B
  

• Orphan clean-up:

  • to be removed: A, C
  • A transitively depends on C
    => C must not be deleted before A

Context

Use case example 1:

• A blueprint offers a flexible deployment of a set of Helm chart releases:
  • Users can specify via blueprint import parameters which Helm releases should be installed.
  • For each Helm chart release a deploy item is used.
  • Helm chart releases have dependencies, expressed as deploy item dependencies.
  • Some dependencies are also relevant for uninstalling Helm releases, e.g. K8s controllers for custom resources.
• A user creates an installation based on the blueprint and enables all Helm releases.
• Later the user updates the installation, disabling some Helm releases that directly or indirectly depend on each other.
  • Landscaper's orphan clean-up removes the deploy items of disabled Helm releases
    • Here the correct order of uninstallations is important!

Use case example 2:

• A blueprint offers a flexible deployment of a set of components.
  • Users can specify via blueprint import parameters which components should be installed.
  • For each component a sub-installation is used.
  • Sub-installations have dependencies, expressed as imports of data objects provided by other sub-installations.
  • Uninstalling a dependent component requires that the dependency still exists.
• A user creates an installation based on the blueprint and enables all components.
• Later the user updates the installation, disabling some components that depend on each other.
  • Landscaper's orphan clean-up removes the sub-installations of disabled components
    • Here the correct order of uninstallations is important!

Proposal Acceptance Criteria

• Orphan clean-ups respect the dependencies between orphans

How much traction does this feature have?

Start by tracing the orphan clean-up path during update reconciliation and compare it with the existing dependency-aware ordering for sub-installations and deploy items. Use the dependency graph from before the update, including indirect dependencies; done means orphan deletions follow that order and satisfy the acceptance criterion.