feat: Re-add .spec.modules[].managed to KymaCR (#1661)

feat: Re-add '.spec.modules[].managed' to KymaCR
kyma-project · Jul 3, 2024 · b47b191 · b47b191
1 parent 93a3385
commit b47b191
Show file tree

Hide file tree

Showing 3 changed files with 47 additions and 1 deletion.
diff --git a/api/v1beta2/kyma_types.go b/api/v1beta2/kyma_types.go
@@ -85,6 +85,11 @@ type Module struct {
 
 	// +kubebuilder:default:=CreateAndDelete
 	CustomResourcePolicy `json:"customResourcePolicy,omitempty"`
+
+	// Managed is determining whether the module is managed or not. If the module is unmanaged, the user is responsible
+	// for the lifecycle of the module.
+	// +kubebuilder:default:=true
+	Managed bool `json:"managed"`
 }
 
 // CustomResourcePolicy determines how a ModuleTemplate should be parsed. When CustomResourcePolicy is set to

diff --git a/config/crd/bases/operator.kyma-project.io_kymas.yaml b/config/crd/bases/operator.kyma-project.io_kymas.yaml
@@ -84,6 +84,12 @@ spec:
                       - CreateAndDelete
                       - Ignore
                       type: string
+                    managed:
+                      default: true
+                      description: |-
+                        Managed is determining whether the module is managed or not. If the module is unmanaged, the user is responsible
+                        for the lifecycle of the module.
+                      type: boolean
                     name:
                       description: |-
                         Name is a unique identifier of the module.
@@ -101,6 +107,7 @@ spec:
                         It will be removed in the upcoming API version.
                       type: string
                   required:
+                  - managed
                   - name
                   type: object
                 type: array
@@ -520,6 +527,12 @@ spec:
                       - CreateAndDelete
                       - Ignore
                       type: string
+                    managed:
+                      default: true
+                      description: |-
+                        Managed is determining whether the module is managed or not. If the module is unmanaged, the user is responsible
+                        for the lifecycle of the module.
+                      type: boolean
                     name:
                       description: |-
                         Name is a unique identifier of the module.
@@ -537,6 +550,7 @@ spec:
                         It will be removed in the upcoming API version.
                       type: string
                   required:
+                  - managed
                   - name
                   type: object
                 type: array

diff --git a/docs/technical-reference/api/kyma-cr.md b/docs/technical-reference/api/kyma-cr.md
@@ -100,11 +100,38 @@ The module mentioned above can be referenced in one of the following ways:
       - name: kyma-project.io/module/sample
     ```
 
+### **.spec.modules[].managed**
+
+For each module, it must be defined whether it is `managed` or `unmanaged`.
+If it is `managed`, Lifecycle Manager takes care of the module's lifecycle (creating, updating, deleting).
+If it is `unmanaged`, Lifecycle Manager ignores the module and the users must take care of the lifecycle themselves.
+To define this, the **managed** flag must be either `true` or `false`.
+By default, the **managed** flag is set to `true` and the module is therefore `managed` by Lifecycle Manager.
+
+```yaml
+spec:
+  channel: regular
+  modules:
+  - name: module-name-from-label
+    managed: true
+```
+
 ### **.spec.modules[].customResourcePolicy**
 
-In addition to this very flexible way of referencing modules, there is also another flag that can be important for users requiring more flexibility during module initialization. The `customResourcePolicy` flag is used to define one of `CreateAndDelete` and `Ignore`.
+A module may be initialized with preconfigured default data.
+To control the configuration, use the **customResourcePolicy** flag.
+The value can either be `CreateAndDelete` or `Ignore`.
 While `CreateAndDelete` causes the ModuleTemplate CR's **.spec.data** to be created and deleted to initialize a module with preconfigured defaults, `Ignore` can be used to only initialize the operator without initializing any default data.
 This allows users to be fully flexible in regard to when and how to initialize their module.
+By default, the **customResourcePolicy** flag is `CreateAndDelete` which makes the module preconfigured.
+
+```yaml
+spec:
+  channel: regular
+  modules:
+  - name: module-name-from-label
+    customResourcePolicy: CreateAndDelete
+```
 
 ### **.status.state**