Plan for migrating Kyma components to new modular arch

[arturskorupa]

Description

Define principal rules for defining interfaces between modules are defined based on all potential use cases of current Kyma components.

Kyma component teams has already everything to start creating their plans to migrate to the new modular architecture: they finished POC about transition to the new architecture to proof feasibility of the concept (also areas to be addressed by further development has been identified - list is kept here).

The goal of this task is to define a plan remaining work for each component. (that will be linked in the relevant acceptance criteria item).
The plan should provide answers on the following questions:

• Is the considered module needed in Kyma
• Are there any blockers the component team foresee based on the current known deliverables from the central reconciler team. What is the remedy (issue for the module team or central reconciler team is a must)
• What date we can expect the module to become GA
• Are there any special requirements for the module (in terms of release management, governance etc.)

Acceptance Criteria

• Principal rules for defining interfaces between modules are defined based on all potential use cases of current Kyma components (dependencies between components)
• Review overrides provided to Kyma Reconciler by KEB and decision is made how new modules are going to consume them (or not?). (MOVED TO another issue Profiles in modular Kyma #16246)
• It is defined which of Kyma modules is available for internal and external usage
• Migration plan for Service mesh
• Migration plan for API Gateway
• Migration plan for Observability/Telemetry (https://github.tools.sap/huskies/knowledge-hub/blob/master/modularization/overview.md, https://github.tools.sap/huskies/knowledge-hub/tree/master/telemetry-module)
• Migration plan for Eventing (https://github.tools.sap/skydivingtunas/proposals/blob/eventing-modularization/eventing-modularization/README.md)
• Migration plan for Application Connector
• Migration plan for Connectivity Proxy
• Migration plan for Compass Runtime Agent
• Migration plan for BTP Operator
• Migration plan for SRE modules
• No other components are left (like certificates, cluster-essentials etc.)

Links

• Concept document
• Transition plan
• Lifecycle manager
• Module manager
• Template operator

[arturskorupa]

Tasks to perform to move component to modular architecture (not exhaustive list):

• create operator for module
• prepare UI
• refactor tests (could happen there's no common integration tests suite any more - Test Strategy for modular Kyma #15442)
• detach from old reconciler and attach to the Lifecycle Manager
• documentation changes
• establish all needed build and governance pipelines

[arturskorupa]

Review overrides provided to Kyma Reconciler by KEB and decision is made how new modules are going to consume them (or not?)

consider a new setting on a module level (provided when the module is getting enabled) e.g. evaluation / production profile

[arturskorupa]

Principal rules for defining interfaces between modules are defined based on all potential use cases of current Kyma components

Missing dependencies has to be handled gracefully by the module-operator. There aren't any common patterns of interaction between components (in current Kyma version) that can be extracted as an interface or principal rule

[pbochynski]

Dependencies should be avoided and minimized. General guideline I am going to add to the modularization concept:

• module operator should know its dependencies
• keep dependencies minimal and try to depend on API only (check if API exists in the required version)
• report missing dependencies in the status of the module operator resource
• remember that dependency can be installed in parallel to your module - give it some time and report error after reasonable timeout
• error or success is not a final state (your dependencies can come and go) - reconcile, update status, bring it to the desired state eventually

[strekm]

as for @kyma-project/goat we started working on istio manager and that will be our focus at first. Istio manager got no dependencies, it will expose Istio CRD as API, proposal can be found here. Istio manager will consist of component managing istio itself, component managing sidecars, component managing other resources (istio-resources, certificates). this will be described in technical design (TBD).

api-gateway module will be worked on later on since it simpler component. It has dependency to Istio CRDs. the will consist of api-gateway controller, ORY stack (as of now). API is not designed yet nor any POCs were done so far

[PK85]

BTP-Operator -> BTP-Manager

• Is the considered module needed in Kyma? Answer: Yes, it's the default module always installed when a new SKR is created. We have a way to make it optional.
• Are there any blockers the component team foresees based on the current known deliverables from the central reconciler team? What is the remedy? Answer: I found that problem and asked the LM team to solve that: Module Manager should restore contents of the resources module-manager#164 (this affects all modules)
• What date can we expect the module to become GA? Answer: Dec/January
• Are there any special requirements for the module (in terms of release management, governance, etc.)? ### Answer: This module requires receiving secret from the central KCP cluster/KEB. Mitigation: KEB provides a secret into the Kyma cluster.

[akgalwas]

Migration plan for Application Connector and Compass Runtime Agent
Application Connector components are tightly coupled with Compass Runtime Agent. Moreover, there is not a big value in a setup without Compass Runtime Agent. After discussions it was decided that Application Connector module will contain the following components: Compass Runtime Agent, Connectivity Validator, and Application Gateway.

Q&A:

• Is the considered module needed in Kyma. A: Application Connectivity is a crucial element of Kyma cluster. It allows user workloads to invoke secured external APIs, and receive events. It can be used along with Eventing and Serverless modules.
• Are there any blockers the component team foresee based on the current known deliverables from the central reconciler team. What is the remedy (issue for the module team or central reconciler team is a must). A: At this point there are no known blockers.
• Are there any special requirements for the module (in terms of release management, governance etc.). A: the module contains Compass Runtime Agent that needs configuration secret to be able to sync-up with Compass. In the current solution Provisioner component is responsible for providing the secret. There will be a new central component called Compass Manager introduced. It will be responsible for:
  • watching Runtimes, and detecting Application Connector module installation
  • registering Runtimes in Compass
  • providing configuration secret for Compass Runtime Agent
• What date we can expect the module to become GA. A: end of Q2 2023 for the Application Connector module itself. As it comes to Compass Manager the expected date is Q4 2023.

The module can be installed even if the secret is not delivered yet by Compass Manager.

Epics created for migration activities:

• Create Application Connector module [EPIC] application-connector-manager#154
• Move Compass Runtime Agent to the new Kyma modular architecture kyma-incubator/reconciler#419

[akgalwas]

Migration plan for Connectivity Proxy
Q&A:

• Is the considered module needed in Kyma. A: Connectivity Proxy has a big value for SAP BTP users.
• Are there any blockers the component team foresee based on the current known deliverables from the central reconciler team. What is the remedy (issue for the module team or central reconciler team is a must). A: At this point there are no known blockers.
• Are there any special requirements for the module (in terms of release management, governance etc.). A: Connectivity Proxy is a proprietary component and as such needs special treatment(e.g. storing in some internal repository). Moreover, there are issues we currently experience with Connectivity Proxy Reconciler that need to be taken into account when working on modularization.
• What date we can expect the module to become GA. A: end of Q3 2023

[arturskorupa]

Review overrides provided to Kyma Reconciler by KEB and decision is made how new modules are going to consume them (or not?).

That topic is being discussed currently, still need some time to conclude.

[ebensom]

Migration Plan for Runtime Monitoring Agent (RMA) and Runtime Monitoring Integration (RMI)

• Is the considered module needed in Kyma: It is a module outside of Kyma, however it is a mandatory module on all SKRs (Kyma runtimes), without the possibility of the cluster users to disable the module.
• Are there any blockers the component team foresee based on the current known deliverables from the central reconciler team: No blockers at this point.
• What date we can expect the module to become GA: 2023.06.01.
• Are there any special requirements for the module (in terms of release management, governance etc.): Availability service level indicator (SLI) depends on Istio sidecar injection, and hence Istio module for these modules:
  • eventing (epp, )
  • application connector (connectivity validator, application gateway)
  • ory (hydra token API)
  • serverless (registry, webhook)

Migration efforts are tracked under https://github.tools.sap/kyma/backlog/issues/3280

[arturskorupa]

It is defined which of Kyma modules is available for internal and external usage

Modules used by customers (presented to them, with or without option to disable):

• Service mesh
• API Gateway
• Observability
• Telemetry
• Eventing
• Application Connector
• Connectivity Proxy
• BTP Operator

Modules for internal use (not presented to customers):

• Compass Manager
• SRE modules (RMI / RMA)

[arturskorupa]

Last open AC (Review overrides provided to Kyma Reconciler by KEB and decision is made how new modules are going to consume them (or not?). ) moved to new issue (#16246)