Iteratively moving forward with module requirements and aligning responsibilities

[c-pius]

Created on 2024-07-12 by Christoph Schwägerl (@c-pius), Xin Ruan (@ruanxin)

Contents

• Change log
• Decision log
• Context
• Key Assumptions and Boundary Conditions
• Decision
• Consequences
• Proposed way forward
  • Status Quo
  • Iteration 1 - Fixed Module Versions and Community Modules
    • Requirements ModuleTemplates
    • Requirements for Community Modules
    • Requirements for Managed/Associated Resources
  • Iteration 2 - Multiple KCPs - Outlook only
• Appendix
  • Proposal for the module publishing pipeline
    • /kyma/module-manifests (PROPOSAL ONLY)
    • /kyma/kyma-modules (PROPOSAL ONLY)

Change log

• v0.0.1 Initial Proposal (2024-07-24)
  • see history for details
• v0.0.2 Updated Proposal (2024-07-31)
  • see history for details
• v0.0.3 Updated Proposal (2024-08-07)
  • see history for details
• v0.0.4 Updated Proposal (2024-08-21)
  • detailed proposal of Alternative D based on previous discussion
  • key feedback:
    • modules are either kyma provided, sap-3rd-party provided, or community provided
    • SAP will not give any SLA on community-provided modules
      • this includes manual installation of kyma- or sap-3rd-party-provided modules
    • sap-3rd-party-modules (transparent- and connectivity-proxy) will not be opened for manual installation
    • managed modules always have an entry in KymaCR
    • kyma/sap-3rd-party-provided modules need to publish ModuleTemplates to support manual installation
    • relying on conventions for resolving resource links is okay, but there needs to be an option to overwrite the convetion
    • using a label to identify installed modules is not enough
      • ModuleTemplates / community module list should rather hold information for identifying the module operator
    • using labels to identify CRDs related to the module is not enough
      • ModuleTemplates / community modules list should rather hold the list of information
    • for unmanaged clusters, customers must first apply the ModuleTemplate so that Kyma dashboard / CLI support installation and discovery
      • if installed without ModuleTemplate by kubectl applying manifests/defaultCR, Kyma dashboard / CLI will not identify them as modules in the cluster
• v0.0.5 Updated Proposal (2024-08-27)
  • changes:
    • added Key Assumptions / Boundary Conditions and updated proposals as of the feedback vom v.0.0.4
  • key feedback:
    • separate ModuleTemplate from channels also in KCP
      • use a separate entity for the channel assignment
      • ModuleTemplate immutable once created
    • fixed version modules mostly intended for manual installation case; check if we can also roll it out in a way that KLM only supports channels in the beginning, and fixed versions may be supported by KLM later on
    • community modules should also use ModuleTemplates
      • GH will be a repo of ModuleTemplates for the community modules
      • CLI/Hasselhoff only discover community modules where the ModuleTemplate has been installed in the cluster
    • once the API is aligned, do a PoC going through the update lifecycle of a module
• v.0.0.6 Updated Proposal (2024-09-18)
  • changes:
    • ModuleReleaseMetaCR added
      • contains release info including the assignment to channels
      • may be extended with further info in the future
    • community modules registered as ModuleTemplates and applied to the SKR by the enduser
    • Key Assumption A4 added that each module has an active manager in the SKR and that the CRD may be used as manager in exceptional cases

Decision log

Name	Description
Title	Iteratively moving forward with module requirements and aligning responsibilities
Due date	2024-08-07
Status	Re-Proposed on 2024-09-25 (v0.0.6)
Decision type	Choice
Affected decisions	#18450 (extends), #1587 (extends)

Context

There are various requirements for modules in Kyma that need to be implemented, i.e.:

• R1: Support for fixed version modules (implicit requirement from #18450)
• R2: Support for community-provided modules
• R3: Kyma modules as OCM components

This decision record aims at aligning a common understanding of a joint way forward supporting these requirements including claryfing some related details.

Key Assumptions and Boundary Conditions

• Key assumption A1: Community modules are always customer managed. I.e., Kyma Lifecycle Manager (KLM) will never manage installation / update / uninstallation of community modules.
• Key assumption A2: Main consumers of the target module list(s) are KLM, Kyma dashboard and Kyma CLI. However, there may be other components in or outside Kyma Control Plane (KCP) interested in the list(s), e.g. telemetry components.
• Key assumption A3: For unmanaged clusters, the customer has to comply to certain requirements in order to benefit from additional discovery / installation mechanisms (i.e., first apply ModuelTemplates to the cluster so that Kyma CLI / dashboard can support with module installation and discovery of installed modules). A consequence of this approach is also that module teams must publish ModuleTemplates if they want to support manual installation.
• Key assumption A4: All modules have a manager in the SKR cluster that is either a Deployment or Stateful set. The existence of this manager is used by Kyma dashboard and CLI to determine if a module is installed. There are exceptional cases, e.g., Cloud Manager, where no active manager is in the SKR. For those cases, the CRD of the module CR will be used as manager and checked for presence in the cluster.
• Boundary condition B1: Build and publication of a module MUST happen only once per version. Once built, versions MUST NOT change. Assignment of a module version to a channel MAY change. This should be explicit in publishing pipelines as well as in KCP.
• Boundary condition B2: SAP 3rd party modules (i.e., transparent-proxy and connectivity-proxy) will not be made available for manual installation.

Decision

The decision is to implement support for the requirements listed in Context as proposed below in Proposed way forward.

Consequences

• [Hasselhoff] Kyma dashboard:
  • consumes kyma module metadata from ModuleTemplates and ModuleReleaseMeta in the SKR
  • identifies installed modules by looking for the manager and checking entries in the KymaCR
• [Jellyfish]
  • enhance ModuleTemplate API with the new fields
  • update modulectl to consider the new fields on creation
  • support ModuleTemplates with fixed versions
  • create ModuleReleaseMeta API and sync it to the SKRs
• [Neighbors]
  • update the module build pipeline to support fixed module versions build and seperate association to channels via ModuleReleaseMeta
• [SRE]
  • update the module publishing pipeline to support fixed module versions and seperate association to channels via ModuleReleaseMeta
• [Otters] Kyma CLI:
  • consumes kyma module metadata from ModuleTemplates and ModuleReleaseMeta in the SKR
  • identifies installed modules by looking for the manager and checking entries in the KymaCR
• [Module Teams]:
  • adapt to register module version and assign them to channels after version build via ModuleReleaseMeta
  • publish ModuleTemplates as part of their release if they want to support manual installation
    • this only includes ModuleTemplates for fixed versions

Proposed way forward

Status Quo

Short recap of the status quo.

• /kyma/module-manifests repo contains the up to date module manifests for each channel
• neighbors-owned pipeline creates the Module Templates and stores them in /kyma/kyma-modules
• neighbors-owned pipeline deploys the Module Templates into the KCP
• KLM reads the Module Templates and synchronizes them into the SKR
• Kyma Dashboard reads the Module Templates from the SKR and displays them to the user

Iteration 1 - Specific Module Versions and Community Modules

Iteration 1 is focusing on enabling support for specifc module versions, community modules and manual installation of modules. The overall process remains close to the status quo. Key changes are:

• module teams release module versions and assign them to channels
• ModuleTemplates refer to a specific module version
  • once built and published to KCP, ModuleTempaltes are not changed anymore
• module versions are assigned to channels
  • this is done via the new resource ModuleReleaseMeta

To support community modules, the following is introduced:

• github.com/kyma-project/community acts as the source for registering community modules
  • see section "Requirements for Community Modules" below for details
• Kyma dashboard and CLI continue to consume ModuleTemplates
  • for Kyma and sap-3rd-party modules, KLM will sync the ModuleTemplates to the SKR
  • for community modules, the end user will have to apply the ModuleTemplate to the SKR

These changes are depicted in the block diagram below.

Remarks: ModuleReleaseMeta CR is synced to the SKR so that Dashboard and CLI can display the available channels

Key considerations for choosing this approach are:

+ there is one single source of truth for module metadata
+ availability of module metdata for KLM is considered guaranteed (resides within the KCP etcd)
+ no operations of additional KCP or public components needed
+ Kyma dashboard and CLI consume the kyma module metadata from the SKR they connect to (no separate config needed)
+ module metadata available within the SKR (e.g. for telemetry module)
- performance overhead for syncing the ModuleTemplates to the SKR
- Kyma dashboard and CLI consume from multiple sources via different approaches

Requirements for ModuleTemplates

ModuleTemplates are deployed into the KCP cluster and KLM syncs them to the SKR. ModuleTemplates may either refer to a fixed module version, or to a channel of a module. Their metadata is changed as follows:

• .metadata.name MUST follow <.spec.moduleName>-<.spec.version>
• .spec.moduleName (new attribute, REQUIRED) MUST define the name of the module
• .spec.version (new attribute, REQUIRED) MUST define the version of the module
  • supersedes the annotation operator.kyma-project.io/module-version
• .spec.data MUST contain the default CR of the module
• .spec.descriptor MUST contain the OCM descriptor for the version specified in .spec.version
  • if the ModuleTemplate defines a module channel, the descriptor MUST be the same descriptor of the version that is currently assigned to the channel
• .spec.mandatory (OPTIONAL) defines whether the module is mandatory. Default is false
• .spec.manager (new attribute REQUIRED) MUST define the info needed to check if the manager is present (used by Kyma dashboard / CLI to check if the module is installed)
  • .group the API group of the manager
  • .version the API version of the manager
  • .kind the kind of the manager
  • .namespace the namespace the manager is deployed in
  • .name the name of the manager
• .spec.info (new attribute REQUIRED)
  • .repository: (REQUIRED) the link to the repository of the module
  • .documentation: (REQUIRED) the link to the module documentation
  • .icons[]: (REQUIRED) list holding links to module icons
    • .name: (REQUIERD): MUST be set to the name of the icon
    • .link: (REQUIRED): MUST be a link to an icon of the module of type SVG
• .spec.resources[]: (new attribute REQUIRED): list containing the the resourecs of the module. Resources MUST be specific to the .spec.version
  • .name: (REQUIRED): MUST be set to the name of the resource
  • .link: (REQUIRED): MUST be the link to the resources
• .spec.associatedResources: (new attribute REQUIRED): list containing the GVK of the CRDs related to the module (will be displayed to the user)
  • group: (REQUIRED)
  • version: (REQUIRED)
  • kind: (REQUIRED)

.spec.info needs to be part of ModuleTemplate as this is also required for commnity modules which don't have a ModuleReleasemeta. Otherwise, it would have been a candidate for being moved there.

Changed/Deprecated fields:

• .spec.channel is deprecated
• annotation "operator.kyma-project.io/module-version": "2.3.1" is deprecated
• .spec.descriptor may become optional in the future once the first community modules arrive

Below is an example of a Kyma module.

Remarks: .spec.descriptor is the OCI descriptor of the module version and used by KLM for installation of the module. .spec.resources[rawManifest] contains the plain manifests of the module for manual installation.

# fixed version module
apiVersion: operator.kyma-project.io/v1beta2
kind: ModuleTemplate
metadata:
  name: api-gateway-2.3.1
  namespace: kcp-system
  labels:
    "operator.kyma-project.io/controller-name": "manifest"
    "operator.kyma-project.io/managed-by": "lifecycle-manager"
spec:
  moduleName: api-gateway
  version: 2.3.1
  data:
    # default CR of module version 2.3.1
  descriptor:
    # descriptor of module version 2.3.1
    # ...
  mandatory: false
  manager:
    group: apps
    version: v1
    kind: Deployment
    namespace: kyma-system
    name: api-gateway-controller-manager
  info:
    repository: https://github.com/kyma-project/api-gateway
    documentation: https://kyma-project.io/#/api-gateway/user/README
    icons:
    - name: default
      link: https://raw.some.host/kyma-project/api-gateway/main/icon.svg
  resources:
  - name: rawManifest
    link: https://raw.some.host/kyma/module-manifests/blob/main/modules/api-gateway/2.3.1/api-gateway-manager.yaml
  associatedResources:
  - group: networking.istio.io
    version: v1alpha3
    kind: gateways
  - group: networking.istio.io
    version: v1alpha3
    kind: virtualservices

Requirements for Module Release Metadata

ModuleReleaseMeta is a new CR that defines the channels a module is available in. In the future, it may be extended with additional information, e.g., an explicit list of installable versions or deprecation info of a module version. The metadata consists of the following:

• .metadata.name (REQUIRED): MUST use the name of the module
• .spec.moduleName (REQUIRED): MUST use the name of the module
• .spec.channels (REQUIRED): MUST list all channels of the module
  • channel (REQUIRED): MUST be the name of the channel
  • version (REQUIRED): MUST be the version that is currently assigned to the channel. There MUST be a ModuleTemplate for the given version.

Below is an example of module release meta.

apiVersion: operator.kyma-project.io/v1beta2
kind: ModuleReleaseMeta
metadata:
  name: eventing
spec:
  moduleName: eventing
  channels:
  - channel: regular
    version: 1.0.0
  - channel: fast
    version: 1.1.0
  - channel: experimental
    version: 2.0.0

Requirements for Community Modules

Community modules are collected at github.com/kyma-project/community. Community modules MUST provide a ModuleTemplate for each released version at /modules/<community module name>/<community module version>. New community modules or versions are registered via Pull Request. As of now, it is assumed that community modules use the same ModuleTemplate as Kyma or sap-3rd-party modules. Once the first community module arrives, this may be revisted depending on the info that is required for the community module.

As of now, the following differences exist when using a ModuleTemplate for a community module:

• KCP/KLM specific labels or annotations MUST NOT be used
• the annotation "operator.kyma-project.io/community-module": "true" MUST be set
• .spec.descriptor MUST NOT be used
• .spec.mandatory MUST NOT be used

For community modules there is NO ModuleReleaseMeta.

Below is an example of a community module.

# github.com/kyma-project/community/modules/cluster-ip/0.0.2/cluster-ip.yaml
apiVersion: operator.kyma-project.io/v1beta2
kind: ModuleTemplate
metadata:
  name: cluster-ip-0.0.2
  namespace: kyma-system
  annotations:
    "operator.kyma-project.io/community-module": "true"
spec:
  moduleName: cluster-ip
  version: 0.0.2
  data:
    apiVersion: operator.kyma-project.io/v1alpha1
    kind: ClusterIP
    metadata:
      name: cluster-ip-nodes
    spec:
      nodeSpreadLabel: kubernetes.io/hostname
  manager:
      group: apps
      version: v1
      kind: Deployment
      namespace: cluster-ip-system
      name: cluster-ip-controller-manager
  info:
    repository: https://github.com/pbochynski/cluster-ip.git
    documentation: https://github.com/pbochynski/cluster-ip#readme
    icons: 
    - name: default
      link: https://github.com/kyma-project/kyma/blob/main/docs/assets/logo_icon.svg
  resources:
  - name: rawManifest
    link: https://github.com/pbochynski/cluster-ip/releases/download/0.0.2/cluster-ip-operator.yaml
  associatedResources:
  - group: operator.kyma-project.io
    version: v1alpha1
    kind: clusterip

Iteration 2 - Multiple KCPs - Outlook only

Iteration 2 is focusing on enabling support for multiple KCPs and publishing/consuming modules from different OCI registries.

• the pipeline for kyma-managed modules is updated to publish to an OCI registry
  • /kyma/module-manifests remains as the origin
  • from there, the modules are built and published as components into the OCI source registry
  • modulectl must be updated to support this. Alternative: it may also be achievable by using the OCM CLI.
• the OCI transfer pipeline takes care of transfering the components into various landscape specific OCI registries
• in KCP, a new component module template publisher is reading the components from the landscape specific OCI registry configured
  • configuration may be a config map, env variable, argument, ...
  • for each component, it creates a respective Module Template that the KLM uses
• Kyma dashboard / CLI continue to consume the community modules directly from github.com
  • may be changed to landscape specific locations/lists

• TODO: detailed proposals for file / registry artifact model to be provided later

Appendix

Discovering modules installed in the cluster

Kyma CLI and dashboard need to identify modules that are installed in the cluster. This includes all kinds of modules (kyma, sap-3rd-party, community) and types of installation (KLM-managed or manual). To achieve this, the manager metadata from the ModuleTemplate is used.
Kyma CLI and dashboard may check if a module manager is present in the cluster and if so, assume that the module is installed. To further disntiguish between KLM-managed and manually installed modules, it can be checked whether the module is included in the KymaCR. If so, it is a KLM-managed installation. If not, or if managed flag is set to false, it is a manual installation.

In order for this to work in unmanaged clusters, the customer must have applied the ModuleTemplate for kyma modules, see Key assumption A3.

Proposal for the module publishing pipeline

The following is just a proposal of how pipelines may be adapted to support above requirements. Eventually, the owning teams decide how they want to implement.

/kyma/module-manifests (PROPOSAL ONLY)

• structure is changed to be version centric (channels will be assigned later to built versions)
• versions
  • define the fixed module versions
  • resources (manifest, defaultCR, associatedResources, manager)
    • remain to have individual entries for each version (not configured centrally per module) as the file name may change between releases
  • associatedResources is a list of group, version, kind
  • version entries are immutable and the build is executed once per version

# /kyma/module-manifests/modules/api-gateway/versions/2.5.0/config.yaml
# module version definition
name: kyma-project.io/module/api-gateway
version: 2.5.0
manifest: api-gateway-manager.yaml
defaultCR: api-gateway-default-cr.yaml
associatedResources: api-gateway-associated-resources.yaml
manager: api-gateway-manager.yaml
beta: false
labels:
  "operator.kyma-project.io/controller-name": "manifest"
  "operator.kyma-project.io/managed-by": "lifecycle-manager"
annotations:
  "operator.kyma-project.io/doc-url": "https://kyma-project.io/#/api-gateway/user/README"
moduleRepo: https://github.com/kyma-project/api-gateway.git
documentation: https://kyma-project.io/#/api-gateway/user/README
icons:
  default: https://raw.some.host/kyma-project/api-gateway/main/icon.svg
resources:
- name: rawManifest
  link: https://raw.some.host/kyma/module-manifests/blob/main/modules/api-gateway/2.5.0/api-gateway-manager.yaml

/kyma/kyma-modules (PROPOSAL ONLY)

• structure is changed to a similar one as in /kyma/module-manifests
• defines the installation info of the built module version
• entries are added by the build pipeline and immutable (a built version is never overwritten)

# ModuleTemplate
# /kyma/kyma-modules/api-gateway/versions/2.5.0/module.yaml
# built module information
apiVersion: operator.kyma-project.io/v1beta2
kind: ModuleTemplate
metadata:
  name: api-gateway-2.5.0
  namespace: kcp-system
  labels:
    "operator.kyma-project.io/controller-name": "manifest"
    "operator.kyma-project.io/managed-by": "lifecycle-manager"
    "operator.kyma-project.io/module-name": "api-gateway"
  annotations:
    "operator.kyma-project.io/doc-url": "https://kyma-project.io/#/api-gateway/user/README"
    "operator.kyma-project.io/is-cluster-scoped": "true"
    "operator.kyma-project.io/module-version": "2.5.0" 
spec:
  moduleName: api-gateway
  version: 2.5.0
  mandatory: false 
  data:
    apiVersion: operator.kyma-project.io/v1alpha1
    kind: APIGateway
    metadata:
      name: default
    spec:
      enableKymaGateway: true
  descriptor:
    component:
      componentReferences: []
      labels:
      - name: security.kyma-project.io/scan
        value: enabled
        version: v1
      name: kyma-project.io/module/api-gateway
      provider: '{"name":"kyma-project.io","labels":[{"name":"kyma-project.io/built-by","value":"cli","version":"v1"}]}'
      repositoryContexts:
      - baseUrl: europe-docker.pkg.dev/kyma-project/modules-internal
        componentNameMapping: urlPath
        type: OCIRegistry
      resources:
      - access:
          imageReference: europe-docker.pkg.dev/kyma-project/prod/api-gateway-manager:2.5.0
          type: ociRegistry
        labels:
        - name: scan.security.kyma-project.io/type
          value: third-party-image
          version: v1
        name: api-gateway-manager
        relation: external
        type: ociImage
        version: 2.5.0
      - access:
          imageReference: europe-docker.pkg.dev/kyma-project/prod/external/oryd/oathkeeper:v0.38.25-beta.1
          type: ociRegistry
        labels:
        - name: scan.security.kyma-project.io/type
          value: third-party-image
          version: v1
        name: oathkeeper
        relation: external
        type: ociImage
        version: v0.38.25-beta.1
      - access:
          imageReference: europe-docker.pkg.dev/kyma-project/prod/external/oryd/oathkeeper-maester:v0.1.5
          type: ociRegistry
        labels:
        - name: scan.security.kyma-project.io/type
          value: third-party-image
          version: v1
        name: oathkeeper-maester
        relation: external
        type: ociImage
        version: v0.1.5
      - access:
          localReference: sha256:b481b8c1e72fea67b6a000ec3e0620e092f56ff0f232510589971d11d3caeb8f
          mediaType: application/octet-stream
          referenceName: raw-manifest
          type: localBlob
        digest:
          hashAlgorithm: SHA-256
          normalisationAlgorithm: genericBlobDigest/v1
          value: b481b8c1e72fea67b6a000ec3e0620e092f56ff0f232510589971d11d3caeb8f
        name: raw-manifest
        relation: local
        type: yaml
        version: 2.5.0
      sources:
      - access:
          commit: 731af19aa7267ef0676812715541bf4e2578cb9e
          repoUrl: https://github.com/kyma-project/api-gateway.git
          type: gitHub
        labels:
        - name: git.kyma-project.io/ref
          value: HEAD
          version: v1
        - name: scan.security.kyma-project.io/rc-tag
          value: ""
          version: v1
        - name: scan.security.kyma-project.io/language
          value: golang-mod
          version: v1
        - name: scan.security.kyma-project.io/dev-branch
          value: ""
          version: v1
        - name: scan.security.kyma-project.io/subprojects
          value: "false"
          version: v1
        - name: scan.security.kyma-project.io/exclude
          value: '**/tests/**,**/test/**,**/*_test.go'
          version: v1
        name: module-sources
        type: Github
        version: 2.5.0
      version: 2.5.0
    meta:
      schemaVersion: v2
  manager:
    group: apps
    version: v1
    kind: Deployment
    namespace: kyma-system
    name: api-gateway-controller-manager
  info:
    repository: https://github.com/kyma-project/api-gateway
    documentation: https://kyma-project.io/#/api-gateway/user/README
    icons:
      default: https://raw.some.host/kyma-project/api-gateway/main/icon.svg
  resources:
  - name: rawManifest
    link: https://raw.some.host/kyma/module-manifests/blob/main/modules/api-gateway/2.5.0/api-gateway-manager.yaml
  associatedResources:
  - group: networking.istio.io
    version: v1alpha3
    kind: gateways
  - group: networking.istio.io
    version: v1alpha3
    kind: virtualservices

• additionally includes the ModuleReleaseMeta that is used to assign versions tochannels
  • this info is manually edited by module teams / SRE
  • define a channel for the module and associate it with a module version
  • channel entries are mutable as current module version in the channel may be changed
• in the future, this may be used to add additional release related info, e.g., explicit list of versions that are isntallable, deprecation info, ...
• ModuleReleaseMeta is picked up by the publishing pipeline and depoyed to the KCP

# ModuleChannel
# /kyma/kyma-modules/api-gateway/module-release-meta.yaml
apiVersion: operator.kyma-project.io/v1beta2
kind: ModuleReleaseMeta
metadata:
  name: api-gateway
spec:
  moduleName: api-gateway
  channels:
  - channel: regular
    version: 1.0.0
  - channel: fast
    version: 1.1.0

[pbochynski]

Just tiny thing: can we get read of long module names? I mean use api-gateway instead of kyma-project.io/module/api-gateway

[ruanxin]

Just tiny thing: can we get read of long module names? I mean use api-gateway instead of kyma-project.io/module/api-gateway

Hi @pbochynski , this long name is for OCM, we need to provide a name which fit for it's naming pattern (<DNS domain> / <name component> { / <name component> }), check here for detail, basically, it requires at least one / to separate domain and component name.

[pbochynski]

Hi @pbochynski , this long name is for OCM, we need to provide a name which fit for it's naming pattern (<DNS domain> / <name component> { / <name component> }), check here for detail, basically, it requires at least one / to separate domain and component name.

Ok I got it. OCM can use long name. But we should not use long names outside of OCM. Can we treat kyma-project.io/module/ as a prefix we always add to the OCM descriptor? In other places like module submission configuration file or module template, we should rather use short names. Do you agree?

[pPrecel]

Great POC :) I love the final shape and the idea of ModuleTemplates as an origin inside the cluster for all modules!

I can imagine two new features for the cli:

• Apply all/specific community-module on a cluster using cli
  This is possible because the github.com/kyma-project/community repo is open-sourced and every cli user can access its data.
• Apply all/specific kyma-module on a self-hosted (not managed) cluster using cli
  I'm not sure if it's even possible because the kyma/kyma-modules repo is private. Do we plan to expose kyma-modules' ModuleTemplates somehow?

[c-pius]

Apply all/specific kyma-module on a self-hosted (not managed) cluster using cli
I'm not sure if it's even possible because the kyma/kyma-modules repo is private. Do we plan to expose kyma-modules' ModuleTemplates somehow?

@pPrecel idea is that module teams have to publish the ModuleTemplate as part of the module. See [Module Teams] part of the Consequences section. Now thinking about it, it may also be a duty of Neighbors who build the stuff currently, and we can think about whether we also want to aggregate those at a central repo (like in the community one) or if we can add it to the release artifacts of the module.