docs: Add docs for unmanaging modules (kyma-project#1936)

* docs: Add docs for unmanaging modules * Suggestions Gosia Co-authored-by: Małgorzata Świeca <[email protected]> * Suggestions Nesma * Note on label removal. * Suggestions Gosia Co-authored-by: Małgorzata Świeca <[email protected]> * move caution under relevant section * Suggestion Gosia Co-authored-by: Małgorzata Świeca <[email protected]> --------- Co-authored-by: Małgorzata Świeca <[email protected]>
nesmabadr · Oct 9, 2024 · 00de055 · 00de055
1 parent 0161c8e
commit 00de055
Show file tree

Hide file tree

Showing 2 changed files with 16 additions and 0 deletions.
diff --git a/docs/contributor/resources/01-kyma.md b/docs/contributor/resources/01-kyma.md
@@ -81,6 +81,20 @@ spec:
 > **CAUTION:**
 > Module referencing using NamespacedName and FQDN (Fully Qualified Domain Name) has been deprecated.
 
+### **.spec.modules[].managed**
+
+The **managed** field determines whether or not the Lifecycle Manager manages the module. By default, it is set to `true`. If you set it to `false`, you exclude a module from management by Lifecycle Manager and trigger the following changes:
+* The module and all its related resources remain in the remote cluster in the same state they were in when the module became unmanaged. 
+* Lifecycle Manager stops reconciling the module and its resources. 
+* The `operator.kyma-project.io/managed-by=kyma` and `operator.kyma-project.io/watched-by=kyma` labels are removed from the module's resources. For example, this may be relevant if you use those labels as exclusion filters for custom monitoring using the Kyma Telemetry module.
+
+To verify that a module was successfully unmanaged, check that the field **.status.modules[].state** has the status `Unmanaged`. Once the state is `Unmanaged`, you can delete the module's entry from **.spec.modules[]** in the Kyma CR.  Nevertheless, the module and its related resources remain in the remote cluster.
+
+> **CAUTION:**
+> When you switch values of **.spec.modules[].managed**, you MUST wait for the new state to be reflected in **.status.modules[].state** before you remove the module's entry from **.spec.modules[]**. If the entry is removed before the current state is reflected properly in **.status.modules[].state**, it may lead to unpredictable behavior that is hard to recover from.
+
+When the **.spec.modules[].managed** field is set back to `true`, Lifecycle Manager starts the module management again. The existing module resources in the remote cluster may be overwritten if the desired state has changed in the meantime, for example, if the module's version within the used channel was updated.
+
 ### **.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`.

diff --git a/docs/user/01-10-kyma-crd.md b/docs/user/01-10-kyma-crd.md
@@ -9,3 +9,5 @@ To get the latest CRD in the YAML format, run the following command:
 ```bash
 kubectl get crd kymas.operator.kyma-project.io -o yaml
 ```
+
+For more information on the fields and how to use them, see [Kyma](../contributor/resources/01-kyma.md).
-Original file line number
+Diff line change
@@ Expand Up @@
     ```bash
     kubectl get crd kymas.operator.kyma-project.io -o yaml
     ```
+    For more information on the fields and how to use them, see [Kyma](../contributor/resources/01-kyma.md).