KymaCR.status.modules not updated on module disabling

[c-pius]

Description

When disabling a module, the module's manifest gets deleted quite swiftly. Watcher logs also indicate that the change is sent from SKR to KCP immediately. However, even after the manifest got deleted, the KymaCR still lists the module under .status.modules[] in Ready state, seemingly until the next scheduled requeue. When this requeue happens, the entry is fully removed from .status.modules[]. When adding a module, the change is immediately reflected in .status.modules[].

Steps to reproduce

reproducable on DEV, STAGE and PROD

• create a cluster on stage
• watch the KymaCR on KCP
• watch the manifests for that kyma on KCP
• disable a module
• observe that the manifest for that module is deleted almost immediately after disabling the module
• observe that the KymaCR continues to list the module under .spec.modules[] in Ready state for a couple of mins (even if the manifest is already completely gone)

Environment Type

Managed

Environment Info

Kubernetes Version: x.y.z Docker Version: x.y.z Kyma CLI Version: x.y.z If used - k3d/k3s/minikube versions

Acceptance Criterias

• [ ] Reproduce this locally and investigate if next AC can be implemented as stated
• [ ] Implement this comment for the following scenario
  • Disabling module, thus corresponding Manifest CR gets marked for deletion
  • While Manifest is not deleted, Kyma CR should be in a Processing state
  • This should already be covered by this test: https://github.com/kyma-project/lifecycle-manager/blob/d51230b9959a0b8a9ae592684e3406f5244909ff/tests/e2e/module_deletion_upgrade_test.go#L45
  • Revisit https://github.com/kyma-project/lifecycle-manager/blob/e1ded83f86ae4023cd100da1d921ae60b246acf0/api/v1beta2/kyma_types.go#L328 to actively set the Processing when Module gets deleted, so Processing update gets not skipped if deletion is "too" fast

[jeremyharisch]

To address this, I suggest that when the Kyma Reconcile loop sends a request to the Kubernetes API (i.e. to delete a Manifest CR), the corresponding Kyma CR should be set into a Processing state. This approach would likely trigger more frequent reconciliation, leading to earlier updates in the Kyma CR status. Additionally, this would clearly indicate that the Kyma instance is still processing changes, rather than incorrectly appearing as fully Ready.