Monitoring associated resources

[ruanxin]

Created on 2024-07-23 by Xin Ruan (@ruanxin)

Decision log

Name	Description
Title	Monitoring associated resources
Due date	2024-07-30
Status	Proposed on 2024-07-23
Decision type	Choice
Affected decisions	-

Context

In the community modules, we introduced associated resources (a list of CRDs), an example here, with feature requests that Module manager should not be undeployed before any managed resource (including module configuration) still exists.

However it's not clear which component should take care monitoring those associated resources.

Decision:

Choice 1: KLM as a central manager to take care of monitoring associated resources during module disabling.

Prons

• Centralized Control: KLM can provide a unified approach to monitor and manage all associated resources, ensuring consistency across all modules.
• Simplified Module Manager Logic: Module Managers do not need to implement their own monitoring logic, reducing complexity.

  Cons

• Increased Complexity for KLM: Adding the responsibility of monitoring associated resources could increase the complexity of KLM, requiring more robust handling and potential performance tuning.
• Low adaptiveness: At the moment, associated resources are only accepted as CRDs. If the module team has a requirement to monitor a specific CR or certain CRDs shared between modules, it is impossible to resolve at the CRD granularity.

Choice 2: Each individual Module Manager takes care of monitoring associated resources.

With this approach, certain contracts should be established between Module Manager and KLM.

1. Module Manager implements it's own monitoring logic in the reconciliation loop.
2. Module Manager takes care of configuring a finalizer into it's Default CR when any associated resources exists.
3. During module disabling, KLM make sure not delete the Module Manager related resources when Default CR still exists, which is an existing feature of KLM.

Prons

• Decentralized Control: Each Module Manager is responsible for its own resources, reducing the burden on KLM.
• Flexible Monitoring Logic: Module Managers can implement more sophisticated monitoring logic as per their own requirements.

  Cons

• Coordination Overhead: Establishing and maintaining contracts between KLM and Module Managers adds an additional layer of coordination.

[ruanxin]

Decision: We go for Choice 2, each individual Module Manager takes care of monitoring associated resources.

Based on this decision, closed following issue: https://github.com/kyma-project/lifecycle-manager/issues/1651 https://github.com/kyma-project/lifecycle-manager/issues/1568