Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Module catalogue improvements ] Extend Kyma CR module list with an explicit version #1589

Closed
3 tasks done
Tomasz-Smelcerz-SAP opened this issue May 31, 2024 · 1 comment
Closed
3 tasks done
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@Tomasz-Smelcerz-SAP
Copy link
Member

Tomasz-Smelcerz-SAP commented May 31, 2024

Description

Note: This issue is just about API change, the change in the controller logic is expected to be implemented here

In order to support explicit module version, we need to add an optional version attribute to the Kyma CR module list.

An example:

Use case 1 / existing: User wants to enable a module in their cluster with the default channel.
[...]
channel: regular
modules:
  - name: my-module
[...]
Use case 2 / existing: User wants to enable a specific channel of a module in their cluster.
[...]
modules:
  - name: my-module
    channel: fast
[...]
Use case 3 / new: User wants to enable a specific version of a module in their cluster.
[...]
modules:
  - name: my-module
    version: 1.0.0
[...]

Reasons

We need this because users must be given an option to install a specific version of the module.
If the user wants to enable a specific module version, a ModuleTemplate CR corresponding to that version must exist in the control-plane.

Acceptance Criteria

  • Add new optional version attribute is to the module list in Kyma CR, which must be a semantic version.
  • Add a validation: either channel or version is present - it is an error to provide both
    • should be validated in the reconciliation loop and present an error in the state for the user
    • can open schema validation support such case? No
  • Add a validation that channel must not be set to none

Examples

# KymaCR
spec:
  channel: regular
  modules:
    - name: template-operator
      version: 2.3.1
# => resolves to template-operator-2.3.1
---
# KymaCR
spec:
  channel: regular
  modules:
    - name: template-operator
# => resolves to template-operator-regular
---
# KymaCR
spec:
  channel: regular
  modules:
    - name: template-operator
      channel: fast
# => resolves to template-operator-fast
---
# KymaCR
spec:
  channel: regular
  modules:
    - name: template-operator
      channel: fast
      version: 2.3.1
# => ERROR: must not have both channel and version set
---
# KymaCR
spec:
  channel: regular
  modules:
    - name: template-operator
      channel: none
# => ERROR: must not use none as a value

Feature Testing

e2e test for the validation. Can be done with local EnvTest.

Testing approach

No response

Attachments

No response

Related issue(s)

#1590

@Tomasz-Smelcerz-SAP Tomasz-Smelcerz-SAP added the kind/feature Categorizes issue or PR as related to a new feature. label May 31, 2024
@c-pius
Copy link
Contributor

c-pius commented Jun 13, 2024

@Tomasz-Smelcerz-SAP FYI: changed the following AC

Add new optional version attribute is to the module list in Kyma CR. Must be a semantic version or a defined identifier like regular or fast (see Introduce New ModuleTemplate API version to support the new Module Catalog #1590).

@ruanxin ruanxin changed the title Extend Kyma CR module list with an explicit version [Module catalogue improvements ] Extend Kyma CR module list with an explicit version Jun 25, 2024
@ruanxin ruanxin self-assigned this Jul 17, 2024
@ruanxin ruanxin removed their assignment Jul 22, 2024
@Tomasz-Smelcerz-SAP Tomasz-Smelcerz-SAP self-assigned this Jul 23, 2024
@c-pius c-pius closed this as completed Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants