KCP ModuleConfig

[ruanxin]

Created on 2023-12-03 by Xin Ruan (@ruanxin)

Decision log

Name	Description
Title	KCP ModuleConfig
Due date	2023-12-30
Status	Proposed on 2023-12-03
Decision type	Binary
Affected decisions	-

Context

For certain SyncResource, relying on end-user configuration in Kyma runtime. However, the Module Manager, responsible for producing SyncResource, is deployed in KCP. To bridge this gap and provide Module Manager with the necessary configuration data, a strategy is needed to transfer it from Kyma runtime to KCP. Refer to the detailed SDD document here.

This ADR defines the concept of ModuleConfig CR mentioned in the document in KCP which is used to persist configuration data.

Decision

• Introduce ModuleConfig to store module configuration data, deployed in KCP.
• Allow ModuleConfig to facilitate filtering by the related Module Manager to retrieve relevant content.
• Module CR in Kyma runtime is the only source to provide the required configuration data for Module Manager consumption.
• Lifecycle Manager is the producer for ModuleConfig, collecting content from the associated Module CR . When the Module CR is created or updated, the Lifecycle Manager will update the corresponding ModuleConfig in KCP.

KCP ModuleConfig example:

apiVersion: operator.kyma-project.io/v1alpha1
kind: ModuleConfig
metadata:
  labels:
    "operator.kyma-project.io/kyma-name": [related kyma name]
    "operator.kyma-project.io/module-name": [related module name]
  name: [unique name]
  namespace: kcp-system
spec:
  kyma: [related kyma name]
  module: [related module name]
  resource: |
      apiVersion: operator.kyma-project.io/v1alpha1
      kind: Infrastructure
      metadata:
        name: default
        namespace: kyma-system
      spec:
        vpcPeerings:
          - name: peering-1
            description: peering-1
            remoteVpcId: vpc-1
            remoteRegion: eu-central-1
            remoteCidrRange:
          - name: peering-2
            description: peering-2
            remoteVpcId: vpc-2
            remoteRegion: eu-central-1
            remoteCidrRange:
        nfsVolumes:
          - name: nfs-1
            description: nfs-1
            size: 100Gi
          - name: nfs-2
            description: nfs-2
            size: 100Gi
       status:
          ...
          state: Ready   
Status:
  conditions:
  - lastTransitionTime: "2023-10-30T15:56:31Z"
    message: module config has been synced
    reason: Ready
    status: True
    type: ModuleConfig
  lastOperation:
    lastUpdateTime: "2023-10-30T15:56:31Z"
    operation: 'module config successfully synced from skr'
  state: Ready

KCP ModuleConfig explain:

• operator.kyma-project.io/kyma-name label enables the Module manager to identify the target Kyma runtime where this config coming from.
• operator.kyma-project.io/module-name label provides the individal Module manager to filter the ModuleConfig which belongs to it.
• spec.kyma (mandatory), specifies the target Kyma name where this module config coming from.
• spec.module (mandatory), specifies which module this module config belongs to.
• spec.resource (mandatory), contains the module CR YAML content as plain text, including the subresource (status) field.
• status.conditions and status.lastOperation indicate the synchronization status and provide information about the last operation performed by the lifecycle manager.
• status.state reflects the current state of the synced ModuleConfig.

[pbochynski]

It makes sense IMHO to extract it from Kyma CR. Watching ModuleConfig with the module labell will be easier. I support the idea.

[koala7659]

This is really interesting proposal, however you must remember about the costs of adjusting existing services that are relying on the contract of the current Kyma Resource schema. For example in Framefrog team in Compass-Manager service we reconcile on change of Kyma resource and we process a list of installed modules. Removing that list from Kyma CR to and making dedicated CRs with that information will force us to change the way how the compass-manager works. Is it possible to keep this list in spec for backward compatibility to minimize the impact?

We expect to be kept in the loop about this proposal and have constructive discussion about migration path from current solution to proposed one.

Please remember that any change in this area will have the impact on the timeline of the finishing of the modularisation project.