Modularization API Upgrade

[janmedrek]

Description

With the features requested the current API of the modularization components is getting outdated, we need to upgrade it to ensure that we can continue to provide support and new features to our users.

Acceptance Criteria

• Remove config layer #543
• Introduce Custom StateCheck Paths in the Module Template #196
• Expose watcher Chart config to Kyma API #296
• Mandatory modules for Kyma instances #890
• Sync resources from control plane to Kyma Runtimes #913
• Add Channel field to Manifest.Spec instead of the Channel label #1477
• Research on tests for API Changes options #1247
• Remove the CustomStateCheck attribute #1709
• [ModuleCatalog] Deprecate .spec.channel in ModuleTemplate #1839
• consider if this should be included: [Module Catalog] ModuleTemplate API: make version and moduleName attributes mandatory #1711
• Rollout plan for the upgrade made
• Documentation for the API adjusted

Reasons

Upgrading the API version of the Lifecycle Manager operator is necessary to ensure that we can continue to provide support and new features to our users. Upgrading the API version will bring many benefits, including better stability, performance, and functionality.

Attachments

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity.
Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

[jeremyharisch]

The field kyma.spec.modules[i].controllername is not used and deprecated. It should be fully removed on next API release.

[ruanxin]

Change to required

• manifest.spec.version
• moduletemplate.spec.mandatoryRequired ModuleTemplate spec.mandatory field after API upgrade #1075
• moduletemplate.spec.info [ModuleCatalog] Add .spec.info to ModuleTemplate #1841
• moduletemplate.spec.resources [ModuleCatalog] Add .spec.resources to ModuleTemplate #1842
• moduletemplate.spec.associatedResources [ModuleCatalog] Add .spec.associatedResources to ModuleTemplate #1843
• moduletemplate.spec.manager [ModuleCatalog] Add .spec.manager info to ModuleTemplate #1840

Add

• moduletemplate.spec.version Remove the fallback to use generation in ComponentDescriptorCache key #995 (comment)

Remove

• manifest.spec.config
• kyma.spec.modules[i].controllername

[janmedrek]

As the discussions started recently - we should revisit how ModuleTemplates are used:

• how can we change/simplify ModuleTemplate CRD?
• is there something we can drop?
• ModuleTemplates should be used specifically for the KLM, not as a source of information for other components/UI
• Perhaps we can drop them and use the same stuff as the UI? It would require using some sort of central module registry

[TorstenD-SAP]

@janmedrek I would not drop the module template at all since it is basically an OCM descriptor. OCM is already part of the North Star Architecture document and will soon be part of the Product Security Standard (there are already discussions ongoing). In addition it will be used in some automation around Vulnerability Management by SGS to identify the owners of container images (an initiative towards that goal is already ongoing). The removal of the corresponding CRD should be no problem.

[janmedrek]

We should not use the stored image version migrator as it is not compatible with GKE clusters (and introduces a massive amount of errors).

If the new version involves schema changes and requires custom logic, a conversion webhook should be implemented in KLM.
If there are no schema changes, the default None conversion strategy may be used in the CRD. Then I would just proceed with the "Option 2: Manually upgrade the existing objects to a new stored version" as documented in the K8S docs, i.e. to have a simple script which list all existing related objects and write them with the same content. This forces the backend to write objects in the current storage version. Then moduify the KLM chart to drop the old version in the CRD status.storedVersions (edited)