Add ModuleTemplate reconciler

[Tomasz-Smelcerz-SAP]

Description

The new Module Catalog uses the ModuleTemplate CR as a main object to represent the Catalog entries. In order to make the implementation robust, we have to define a contract: What is allowed and what is not allowed with respect to ModuleTemplate object creating, deleting and editing.
Otherwise the users (or control-plane administrators) are free to manipulate the set of defined ModuleTemplates in any way they want, not necessarily the one that conforms to the assumptions we made during the analysis or the implementation choices we made.

The ModuleTemplate reconciliation is required for:

New ModuleTemplate Creation

• Every created ModuleTemplate is validated upon creation. Invalid ModuleTemplate is marked as such and cannot be used for the purpose of adding the module it represents to a Kyma object.

ModuleTemplate Deletion

• Deletion of any valid ModuleTemplate is blocked by the LifecycleManager if the module it represents is currently used by some Kyma object(s).
  This is required because our system should be consistent: There should be no Kyma CRs with a modules that do not have a corresponding entry in the Module Catalog - as defined by the Lifecycle Manager API.

ModuleTemplate Editing

• What kind of changes are allowed? Maybe the ModuleTemplate should be immutable?
  The easiest implementation would be to make the ModuleTemplate immutable. After all, the Catalog (of anything) - assuming no mistakes - shouldn't need any editing. The new entries are just appended and the old, deprecated entries are removed.
  But taking into account the real world scenarios, where mistakes do happen, we should allow for some editing.
  The scope of it is to be decided later, once we have the reconciliation logic.

ModuleTemplate Deprecation (Optional)

• Before deleting ModuleTemplate, users should be able to deprecate given Module Catalog entry (a ModuleTemplate CR).
  The deprecated ModuleTemplate cannot be used to the module it represents to any Kyma object, but existing usages continue to work. What happens if the user deprecates the most recent ModuleTemplate for some module within the regular channel? Nobody is able to add this module to any Kyma CR using regular channel anymore, but existing configurations still work.

Reasons

As for now, the Module Catalog contract is defined outside the Lifecycle Manager and is even defined in a non K8s-way.
In order to provide a robust implementation of the enhanced Module Catalog, we need to model it in terms of K8s resources that are then consumed by the Lifecycle Manager.
For us it is best to define the mentioned contract and K8s objects to be used as a part of the Lifecycle Manager API upon which we have direct control.
This shields the Lifecycle Manager from intentional or unintentional changes of the established Module Catalog rules and allows us to require our users to conform to the defined contract.

Acceptance Criteria

• Extend the ModuleTemplate CR with necessary attributes: status sub-resource, deprecated flag (optional) etc.
• Add the ModuleTemplate reconciler
• Implement basic validation during ModuleTemplate creation - as described. Add more validations if there are some obviously required ones.
• Prevent deletion of ModuleTemplates that are "used" (the modules they defined are currently managed on some Kyma CRs)
• Determine the scope of allowed editing actions and implement it (it may be fully editable in the first iteration, then create a follow-up issue to strengthen it later on)
• Add the ability to deprecate a ModuleTemplate CR
• Create a follow-up issue to implement necessary changes to the Kyma controller (one cannot install deprecated modules)

Feature Testing

unit tests, integration tests, e2e tests

Testing approach

As with the other reconcilers

Attachments

No response

Related issue(s)

#1472

[Tomasz-Smelcerz-SAP]

The decision taken by the team is to NOT implement the ModuleTemplate reconciler at the moment.