-
Notifications
You must be signed in to change notification settings - Fork 30
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
Extend module template with the managed CRDs #963
Comments
one proposal:To support the list of managed CRDs, can we put it into some resources, for example, a configmap, or even a dedicated CR. Then LM can deploy it to SKR as a normal module resource during module enabling. The CLI, busola can use this configmap to cleanup blocking resources during module deleting. If module is stuck under delete, anyway LM blocks all the module resources to be deleted, so this configmap will present in SRK before module CR get deleted. |
I was thinking about adding that information to the module template spec. We can add it to module metadata and then CLI can pass it to the module template. No work for KLM. Just one additional field to process by Kyma CLI create module command. What do you think? |
Hi @pbochynski , thanks for the answer, actually, I have some concerns if it's good to put this information in module template.
If point 1 is irrelevant, I think we can go with your idea. |
I think introducing another config map or another CR for describing module is not the best approach. Let me use the example. Right now module contributors have to provide metadata (module-config.yaml). This is the config for serverless with additional CRD list:
which will produce such module template:
Now about your concerns above.
|
@valentinvieriu You probably should tell us your preference, as you are a customer of this feature :) |
Hi @pbochynski,
I got your point, I think I need to clarify the use case I'm concerned about more clearly. The use case is when Kyma CR is under deletion, the ModuleTemplate which synced to remote SKR cluster will be deleted, in this case, there is no moduletemplate for Kyma dashboard (or kyma CLI) to consume with. So the question is during cluster deprovision, is it necessary to let customers still possible to use some tools like Kyma CLI to interactive cluster to force delete module so that cluster can be deprovision faster, maybe it's not needed, eventually the cluster should be deleted automatically. tbh, another reason I'm not telling is, actually I plan to convince you to stop module template sync in the future, but this is just an immature idea atm. I see this module template which synced in remote cluster, they just serve the feature:
However, introducing more responsibilities into the module template basically makes this option impossible. |
Kyma deprovisioning is something different. If Kyma is deprovisioned we already have a logic to clean up all resources in the SKR. Another topic is what should be synced to the cluster. I see potential optimization in making the module template smaller (skip some irrelevant OCM fields) or consolidating it into one resource. But for me it is just optimization. We need a list of available modules with their metadata in the target cluster. Right now for that purpose, we have ModuleTemplate CRs. I am not sure if replacing that list with single resource is going to change the KLM performance significantly. If you say that it reduces reconciliation time more than 20% we should start such initiative. |
This issue or PR has been automatically marked as stale due to the lack of recent activity. This bot triages issues and PRs according to the following rules:
You can:
If you think that I work incorrectly, kindly raise an issue with the problem. /lifecycle stale |
As we talked with @pbochynski there are two options for determining a list of managed CRDs: #1211 (comment) For now, I will close this issue, if we decide to go that way we will reopen it and continue the work here. |
Description
We need the information about CRDs installed by the module for Kyma Dashboard and Kyma CLI. The information can be extracted from the module manifest, but it is not always the complete list (sometimes CRDs are installed by the module operator). It makes sense to have an explicit list of CRDs in the module template spec.
Reasons
No response
Acceptance Criteria
Feature Testing
No response
Testing approach
No response
Attachments
No response
The text was updated successfully, but these errors were encountered: