All Modules MUST Provide Default Module CR Data Except Mandatory Modules

[c-pius]

Created on 2025-02-18 by Christoph Schwägerl (@c-pius).

Decision log

Name	Description
Title	All Modules MUST Provide Default Module CR Data Except Mandatory Modules
Due date	2025-03-05
Status	Proposed on 2025-03-05
Decision type	Choice
Affected decisions	None

Context

Modules are configured via the Module CR. Lifecycle-manager supports to install a default Module CR to the SKR when the module is enabled with CustomResourcePolicy: CreateAndDelete. This default Module CR is found in the ModuleTemplate CR under .spec.data.

The .spec.data field of the ModuleTemplate CR is optional (see required fields).

There has been some unclarity whether .spec.data is truly optional which needs to be clarified. E.g., Kyma dashboard needs to know if they can rely on .spec.data being there for all ModuleTemplate CRs they work with.

Key Assumptions

Mandatory modules are not configurable

Mandatory modules are not configurable on SKR side as the are "hidden" from the end user. Therefore, mandatory modules do NOT have a default Module CR.

ModuleTemplate CRs for mandatory modules are not synced to the SKR

KLM only syncs ModuleTemplate CRs for "regular" modules to the SKR. The ModuleTemplates of mandatory modules are not synced to the SKR as they are "hidden" from the end user.

Community modules may come without default Module CR

Community modules are NOT installed by lifecycle-manager. The notion of a default Module CR doesn't provide meaning in the context of community modules.

Decision

All "regular" modules, this includes Kyma- and community-provided ones, MUST provide a Module CR. This Module CR is used for configuration and status reporting.

The .spec.data of the ModuleTemplate CR defines the default Module CR. For Kyma-provided modules, this is the Module CR that is created by lifecycle-manager with CustomResourcePolicy: CreateAndDelete. For community-modules, it has informational character.

Consumers can take the GroupVersionKind from the entry in .spec.data to determine the CRD of the Module CR. The decision which of the Module CRs is "leading" if there are multiple is decided separatly in Aligned approach for Handling Module CRs.

Consequence

The module publishing pipeline is updated to require a default Module CR unless the module is marked as mandatory.

Consumers of the ModuleTemplate CR in the SKR can expect default Module CR data to be present but need to be robust to not fail in case there isn't one. The default Module CR can be assumed the "leading" Module CR if present. Otherwise, see Aligned approach for Handling Module CRs for alterantives.

[c-pius]

Also related to: https://github.com/kyma-project/community/issues/921

[c-pius]

Feedback 2025-03-12:

• we can enforce the need for default Module CR in the publishing pipeline
• consumers can expect the data to be present, but should be robust to handle the case where it is not found

[halamix2]

We've (Otters) created a new module registry-proy (https://github.tools.sap/kyma/registry-proxy). This module is very simple, it's just a module that allows user to create reverse-proxies that can be used to download Docker images through Connectivity Proxy. Since it doesn't require any user configuration we don't have any CR for the module itself, but we're a bit blocked now because of that

[c-pius]

Thanks for explaining. From lifecycle-manager perspective, the most important use case for the module CR is the safe deletion, see https://github.com/kyma-project/community/issues/972. If there is no module CR, lifecycle-manager will immediately delete the whole module without giving the customer a chance to do some clean up. Would that be okay for this module?

@mrCherry97 how about Kyma dashboard? I think you also mentioned that you have some use case requiring a module CR. Could you live without it for certain modules?

[kwiatekus]

@c-pius Thanks.

Would that be okay for this module?

No its not ok. We need to ensure safe deletion. Otherwise user might unconsciously brake his setup. We will add extra control loop for module CR so that module deletion contract and the status reporting towards Kyma dashboard are both satisfied (issue)

[mrCherry97]

To be honest, I don't remember all the use cases clearly. This change will reduce our calls to find the module, which was our main use case, and it will be a lot easier for us to get some data about the module itself.