search

kyma-project / lifecycle-manager

Controller that manages the lifecycle of Kyma Modules in your cluster.
http://kyma-project.io
Apache License 2.0
9 stars 30 forks source link

Modularization API upgrade #776

Open janmedrek opened 11 months ago

janmedrek commented 11 months ago

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

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 commented 6 months ago

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:

You can:

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

/lifecycle stale

jeremyharisch commented 6 months ago

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

ruanxin commented 6 months ago

Change to required

Add

Remove

janmedrek commented 6 months ago

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

TorstenD-SAP commented 5 months ago

@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 commented 4 months ago

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)