Use explicit ModuleTemplate .spec.manager info to determine the module manager

[c-pius]

Description

We determine the manifest state based on the state of its manager here: https://github.com/kyma-project/lifecycle-manager/blob/main/internal/manifest/statecheck/state_check.go

Right now, we determine the manager implicitly, i.e., the first deployment or stateful set that we find as part of the module resources. With #1840 we will introduce explicit information what the manager of the module is. We should use this to refactor this implicit determination of the manager.

Reasons

More explicit code, less prone to errors (not only manager deployment in raw manifest)

Acceptance Criteria

• manager explicitly looked up by the GVK info from the ModuleTemplate
  • if not present in the manifest => throw an error (may already be validated long before the state check)
  • if not found in the SKR
    • within 1 min of creation of the ManifestCR => return state.Processing
    • after 1 min of creation of the ManifestCR => return state.Error
• create e2e tests covering all three cases above

Feature Testing

No response

Testing approach

No response

Attachments

No response

[c-pius]

Blocked right now until ADR is completed and API change is implemented.

[c-pius]

When rolling out the current state check without the explicit manager, we experienced problems with Cloud Manager. The key assumption that every module has a manager deployed to the cluster doesn't hold, as Cloud Manager is a KCP component.

For Cloud Manager, we only deploy the CRD to the SKR. If this fails, we already error out before determining the manager state. We could allow the CRD to be specified as manager (field name is then questionable, but I would say it is okay given that this should be an exceptional case). With that, we would have 3 supported state checks from KLM perspective:

type Manager struct {
	group,
        version,
        kind,
        namespace,
        name
}

type ManagerStateCheck struct {
       // holds 
       // "deployment"=>DeploymentStateChecker: checks based on deployment resources
       // "statefulset"=>StatefulSetStateChecker: checks based on statefulset resources
       // "crd"=>CRDStateChecker: checks based on the CRD conditions (should have Established, NamesAccepted and NOT Terminating)
       checkers map[string]StateChecker
}

func (m *ManagerStateCheck) GetState(ctx context.Context, mngr Manager, resources []*resource.Info) (shared.State, error) {
  if checker, hit := m.checkers[mngr.kind]; !hit {
    return shared.StateError, ErrNoCheckForGivenKind
  }
  return checker.GetState(ctx, mngr, resources)
}

For Kyma dashboard / CLI not much changes. They take the manager info and check if the resource is there in the SKR. If so, it is assumed that the module is installed.

[c-pius]

Closing this issue as we are not aiming to use this info in lifecycle-manager. We should rather have a follow-up where it is clarified what states the end user needs exactly, and who is responsible for providing what, e.g.:

• Manifest.Status => only tells if KLM was able to apply the manifest
• DefaultCR.Status => tells if the module is functional
• Manager.Status => tells if the module's manager is up and running, affects the DefaultCR.Status