Merge branch 'main' into feature/kyma-project#1890-tls-cert-rotation-…

…migration

config/control-plane/kustomization.yaml

@@ -66,6 +66,17 @@ patches:
         value: --is-kyma-managed
     target:
       kind: Deployment
+  - patch: |-
+      - op: add
+        path: /metadata/labels
+        value: {}
+      - op: add
+        path: /metadata/labels/grafana_dashboard
+        value: "1"
+    target:
+      kind: ConfigMap
+      name: dashboard-(overview|status|watcher|mandatory-modules)
+      version: v1
     # [WEBHOOK] To enable webhook, uncomment all the sections with [WEBHOOK]
   - path: patches/unique_manager_webhook_patch.yaml
   - path: patches/adjust_resources_in_deployment.yaml
@@ -77,9 +88,7 @@ patches:
     # kubebuilder operators.
   - path: patches/unique_certificate_name.yaml
 
-# We patch the Metrics ConfigMaps here, as we expect KCP to be watching for grafana dashboards in the 'kyma-system' namespace.
-# Note1: Now as the 'patchesJson6902' is deprecated, the direct use of the 'PatchTransformer' is the only way to change a resource namespace to something different from the value configured by the global namespace transformer.
-# Note2: the 'grafana_dashboard' label could be applied using a standard JSON patch, but a namespace must be patched here and it's better to have all related customizations in a single place. 
+# Note: Now as the 'patchesJson6902' is deprecated, the direct use of the 'PatchTransformer' is the only way to change a resource namespace to something different from the value configured by the global namespace transformer.
 transformers:
 - |-
   apiVersion: builtin
@@ -112,46 +121,6 @@ transformers:
     path: metadata/annotations
   - kind: ValidatingWebhookConfiguration
     path: metadata/annotations
-- |-
-  apiVersion: builtin
-  kind: PatchTransformer
-  metadata:
-    name: fix-dashboard-overview-cm
-  patch: '[{"op": "replace", "path": "/metadata/namespace", "value": "kyma-system"}, {"op": "add", "path": "/metadata/labels/grafana_dashboard", "value": "1"}]'
-  target:
-    kind: ConfigMap
-    name: klm-dashboard-overview
-    version: v1
-- |-
-  apiVersion: builtin
-  kind: PatchTransformer
-  metadata:
-    name: fix-dashboard-status-cm
-  patch: '[{"op": "replace", "path": "/metadata/namespace", "value": "kyma-system"}, {"op": "add", "path": "/metadata/labels/grafana_dashboard", "value": "1"}]'
-  target:
-    kind: ConfigMap
-    name: klm-dashboard-status
-    version: v1
-- |-
-  apiVersion: builtin
-  kind: PatchTransformer
-  metadata:
-    name: fix-dashboard-watcher-cm
-  patch: '[{"op": "replace", "path": "/metadata/namespace", "value": "kyma-system"}, {"op": "add", "path": "/metadata/labels/grafana_dashboard", "value": "1"}]'
-  target:
-    kind: ConfigMap
-    name: klm-dashboard-watcher
-    version: v1
-- |-
-  apiVersion: builtin
-  kind: PatchTransformer
-  metadata:
-    name: fix-dashboard-mandatory-modules-cm
-  patch: '[{"op": "replace", "path": "/metadata/namespace", "value": "kyma-system"}, {"op": "add", "path": "/metadata/labels/grafana_dashboard", "value": "1"}]'
-  target:
-    kind: ConfigMap
-    name: klm-dashboard-mandatory-modules
-    version: v1
 - |-
   apiVersion: builtin
   kind: PatchTransformer

docs/contributor/01-architecture.md

@@ -20,9 +20,9 @@ To run, Lifecycle Manager uses the following workflow:
 
 2. A runtime Admin adds and/or removes modules using a Kyma CR. The Kyma CR represents Kyma installation on a cluster. It includes a list of installed modules and their statuses. Lifecycle Manager watches the CR and uses the synchronization mechanism to update it on a cluster. Together with the Kyma CR, Lifecycle Manager reads also the kubeconfig Secret to access the Kyma runtime.
 
-3. To manage a module, Lifecycle Manager requires a ModuleTemplate CR. ModuleTemplate CR contains the module's metadata. It represents a module in a particular version. All ModuleTemplate CRs exist in Kyma Control Plane which is the central cluster with Kyma infrastructure. Lifecycle Manager uses those ModuleTemplate CRs to create a Module Catalog with ModuleTemplate CRs available for a particular Kyma runtime. Lifecycle Manager creates the Module Catalog based on labels, such as `internal`, or `beta`, and uses the synchronization mechanism to update the Module Catalog portfolio.
+3. To manage a module, Lifecycle Manager requires its definition and version-related metadata. The ModuleTemplate and ModuleReleaseMeta CRs represent the definition and version-related metadata for a module. The ModuleTemplate CR represents a module in a particular version, while the ModuleReleaseMeta CR describes the mapping between module versions and available channels. All ModuleTemplate CRs, along with their related ModuleReleaseMeta CRs, exist in Kyma Control Plane which is the central cluster with Kyma infrastructure. The set of ModuleTemplate CRs and related ModuleReleaseMeta CRs available for a particular Kyma runtime is called the Module Catalog. Lifecycle Manager creates the Module Catalog based on labels, such as `internal`, or `beta`, and uses the synchronization mechanism to update the Module Catalog portfolio.
 
-4. Lifecycle Manager reads a ModuleTemplate CR and creates a Manifest CR. The Manifest CR represents resources that make up a module and are to be installed on a remote cluster by Lifecycle Manager.
+4. Lifecycle Manager uses ModuleReleaseMeta and ModuleTemplate CRs to read a module's definition and create a Manifest CR. The Manifest CR represents resources that make up a module and are to be installed on a remote cluster by Lifecycle Manager.
 
 5. Lifecycle Manager reconciles, namely watches and updates, a set of resources that make up a module. This process lasts until a module is listed in the remote cluster Kyma CR.
 

docs/contributor/resources/01-kyma.md

@@ -114,7 +114,7 @@ The conditions represent individual elements of the reconciliation that can eith
 Currently, we maintain conditions for:
 
 * Module (Manifest CR) synchronization
-* Module Catalog (ModuleTemplate CR) synchronization
+* Module Catalog (ModuleTemplate CR and ModuleReleaseMeta CR) synchronization
 * Watcher Installation Consistency
 
 We also calculate the **.status.state** readiness based on all the conditions available.

docs/contributor/resources/README.md

@@ -10,7 +10,7 @@ The API of Lifecycle Manager is based on Kubernetes Custom Resource Definitions
 ## Synchronization of Module Catalog with Remote Clusters
 
 Lifecycle Manager ensures the Module Catalog is correctly synchronized with users' runtimes.
-The Module Catalog consists of all modules, represented by ModuleTemplates CR, that are available for a user. The Module Catalog portfolio may vary for different users.
+The Module Catalog consists of all modules, represented by ModuleTemplate CRs and related ModuleReleaseMetas CRs, that are available for a user. The Module Catalog portfolio may vary for different users.
 The synchronization mechanism described below is essential to allow users to enable modules in their clusters.
 The mechanism is controlled by the set of labels that are configured on Kyma and ModuleTemplate CRs in the Control Plane. The labels are: `operator.kyma-project.io/sync`, `operator.kyma-project.io/internal`, and `operator.kyma-project.io/beta`.
 The v1beta2 API introduces three groups of modules:
@@ -20,6 +20,7 @@ The v1beta2 API introduces three groups of modules:
 * Beta modules, synchronized per-cluster only if configured explicitly on the corresponding Kyma CRs. To mark a ModuleTemplate CR as `beta`, use the `operator.kyma-project.io/beta` label and set it to `true`.
 
 By default, without any labels configured on Kyma and ModuleTemplate CRs, a ModuleTemplate CR is synchronized with remote clusters.
+For every synchronized ModuleTemplate CR, all related ModuleReleaseMetas CRs are synchronized as well.
 
 **NOTE:** The ModuleTemplate CRs synchronization is enabled only when Lifecycle Manager runs in the control-plane mode. Lifecycle Manager running in the single-cluster mode, doesn't require any CR synchronization.