Clarify statehandling for "installation state", "manager state", "business state"

[c-pius]

Description

Follow-up from discussing: #1831

kyma-project/community#899 aligned that a module's state is separated into two distinct statues:

• a) the "installation state"
  • determines if the module has been installed successfully
  • written by KLM
  • written as ManifestCR.status, synced into KymaCR.status.modules[].status
• b) the "business state"
  • determines if the module is functioning as expected (failures caused e.g. by invalid configurations)
  • written by the module manager
  • written as `DefaultCR.status

For the "installation state", KLM is currently considering two things, first whether the resources from the raw manifest were applied successfully, second whether the module manager (deployment or replica set) came up successfully. The second step currently raises some concerns as KLM is just looking for the first deployment / replica set in the manifest and assumes it is the module manager, even if there is a problem with the manager coming up, KLM cannot resolve this situation.

Therefore the question, whether this should be re-designed. E.g., the UI could use the manager information from the new module templates and directly display its state.

Reasons

Have a consistent and transparent state management.

Acceptance Criteria

• Clarified how we want to continue with the state handling
• Created the necessary follow-ups as needed

Feature Testing

No response

Testing approach

No response

Attachments

No response