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

[ModuleCatalog] Add .spec.manager info to ModuleTemplate #1840

Closed
3 tasks done
c-pius opened this issue Sep 6, 2024 · 2 comments
Closed
3 tasks done

[ModuleCatalog] Add .spec.manager info to ModuleTemplate #1840

c-pius opened this issue Sep 6, 2024 · 2 comments
Assignees
Labels
API Denotes that an issue is tied to the potential change of the API kind/feature Categorizes issue or PR as related to a new feature.

Comments

@c-pius
Copy link
Contributor

c-pius commented Sep 6, 2024

Description

In #1681 it has been decided to add explicit information identifying a module's manager to the ModuleTemplate. We need to update the ModuleTemplate to include this information.

The information shall look as follows:

spec:
  manager:
    group: <group>
    version: <version>
    kind: <kind>
    namespace: <namespace>
    name: <name>

.spec.manager is OPTIONAL (for compatibility reasons), but the individual entries are REQUIRED, except Namespace which can be OPTIONAL due to CRDs not being namespaced. It should be checked whether existing K8s types and validations can be re-used.

Reasons

Enables CLI and dashboard to determine whether a module is installed or not (manual installation case)

Acceptance Criteria

  • re-used K8s types if possible
  • .spec.manager added to ModuleTemplate
  • Added an entry to Modularization API Upgrade #776 that .spec.manager must be added as required in a future major API version

Feature Testing

No response

Testing approach

No response

Attachments

No response

@c-pius c-pius added kind/feature Categorizes issue or PR as related to a new feature. API Denotes that an issue is tied to the potential change of the API labels Sep 6, 2024
@janmedrek
Copy link
Contributor

Let's reconsider other options such as introducing a new resource just for CLI/UI monitoring purpose.

@c-pius
Copy link
Contributor Author

c-pius commented Oct 2, 2024

Discussed this quickly in the arch meeting today. PB (not present, only left a comment), is okay with the proposal that an arbitrary resource may be provided. If the resource is present, it is assumed that the module is installed in the cluster. We can make the namespace optional to support cluster scoped resources.

Still, the expected resource to be provided is the module manager (deployment). Should we nevertheless rename the field or keep manager?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Denotes that an issue is tied to the potential change of the API kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

4 participants