Skip to content

Commit

Permalink
Suggestion Gosia
Browse files Browse the repository at this point in the history
Co-authored-by: Małgorzata Świeca <[email protected]>
  • Loading branch information
c-pius and mmitoraj authored Oct 9, 2024
1 parent 113bfc4 commit 11e7ed2
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion docs/contributor/resources/01-kyma.md
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ The **managed** field determines whether or not the Lifecycle Manager manages th
* 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.

Once a module was successfully unmanaged, the module's status in **.status.modules[].state** shows `Unmanaged`. Once the `Unmanaged` state shows, the module's entry can also be deleted entirely from **.spec.modules[]**. As the module is already unmanaged, this still leaves the module and its related resources in the remote cluster.
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.
Expand Down

0 comments on commit 11e7ed2

Please sign in to comment.