Kyma module as OCM component

[ruanxin]

Created on 2024-05-28 by Xin Ruan (@ruanxin)

Decision log

Name	Description
Title	Kyma module as OCM component
Due date	2024-06-30
Status	Proposed on 2024-05-28
Decision type	Binary
Affected decisions	-

Context

To ensure efficient deployment of all Kyma Control Plane (KCP) components and Kyma modules across multiple KCP landscapes, we will adopt the Open Component Model (OCM) as the standard for describing these components. This standardization will facilitate consistent delivery and management of software bills of delivery (SBOD) for KCP components.

Decision:

Each Kyma module will be defined as an OCM component. This involves specifying several required and optional OCM resources for each module.

Naming convention

Prefix each module with kyma-project.io/module/ followed by the module's short name to comply with the OCM component naming pattern.

OCM Resources Definition

The following table describes the required and optional resources for each Kyma module:	Resource Name	Type	Definition
default-cr	directory	[Required] the module Default CR, provided by module team in github release as assets, e.g: in this keda-manager release, it's keda-default-cr.yaml
raw-manifest	directory	[Required] the module resources, provided by module team in github release as assets, e.g: in this keda-manager release, it's keda-manager.yaml
all module image name	ociArtifact	[required] All module images, including those managed by the module, each image is a dedicated ociArtifact resource
associated-resources	plainText	[optional] for those managed module which have managed resources, provided by module team in github release as assets, this content will be the source of truth for providing the associatedResources field in module configuration, check an example for keda module here
localization	plainText	[optional] to be compatible with ocm-controller, we provided this additional localization ConfigData resource for localization purposes, for the detailed usage, check the ocm-controller document

Kyma Module Deployment resources

To ensure the Kyma Lifecycle Manager (KLM) can replace localized module images during deployment, all required images must be listed in the Module Operator Deployment Kubernetes resource. Images are categorized into two groups:

• module operator images: All the images listed in module Deployment as container images.
• module managed images: Images deployed by certain module managers during runtime, for example, btp-manager will deploy sap-btp-service-operator, for this kind of usages, each image must be provided in module Deployment as a dedicated container env value.

All images must be published and signed in the central image registry: europe-docker.pkg.dev/kyma-project/prod

Consequences:

Adopting this approach will streamline the deployment process, enhance consistency across different environments, and provide a clear structure for managing module resources. It will also support localization needs and integration with KLM or existing OCM tools.

[ruanxin]

an example:

ocm get resource ghcr.io/ruanxin/kcp-source//kyma-project.io/module/template-operator -c 1.0.0 -owide
NAME         VERSION IDENTITY TYPE        RELATION ACCESSTYPE  ACCESSSPEC
default-cr   1.0.0            directory   local    localBlob   {"localReference":"sha256:7b747b3bbc6504c3198c52c764508f0217a39f44cb4ee52ed5f67b3b0fb6df9e","mediaType":"application/x-tar"}
module-image 1.0.0            ociArtifact external ociArtifact {"imageReference":"europe-docker.pkg.dev/kyma-project/prod/template-operator:1.0.0"}
raw-manifest 1.0.0            directory   local    localBlob   {"localReference":"sha256:ad76888e8aee1c337eed330443cae54b4f912824e9c17c0f876e48d12f8ad65d","mediaType":"application/x-tar"}

[pbochynski]

lgtm