-
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
Separate business and module statuses #1471
Comments
FYI the runtime-monitoring-operator watches Kyma CR statuses on KCP and uses that to know which modules are enabled and in what current state they are in. This epic for sure will impact RMO Kyma controller. |
Thanks, @ebensom! Will make sure you are involved in the discussions regarding all the API changes. |
9 tasks
Acceptance Criteria for EPIC:
Timebox: 2 Days |
3 tasks
4 tasks
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
As decided in this proposal there should be a clear separation of business and manifest states for the modules.
Lifecycle Manager should only care about the Manifest, whether it was deployed correctly and whether the deployment is up and running. It should not be concerned about proper module configuration, which is on the user side.
As for the Kyma state - it should be an aggregation of manifest states of the manifests.
Reasons
Quite often state of module business logic is not related to the health of its deployment. We want users and operations teams to have a transparent overview of what is going on with the module.
Acceptance Criteria
All the changes should be synchronised with Busola so that all the states are displayed correctly
Open Questions
What would be a transparent naming for two different states (to not confuse the user)?
state
to something likemanifestState
How can we inform users of available modules if Module Templates are not synchronised?
the solution is easy for Busola, we should also include this information somewhere in the cluster
Should we somehow sync Module States to the KCP/Kyma? This may improve the transparency on overall module health and potential issues. This is also relevant for the RMO as it is consuming the KCP Kyma CR to provide info on all the modules.- RMO does care only about whether the module was enabled/disabled and if the action was successful, as long as there is an entry in the Kyma CR status section it is fineShould we keep both states in Kyma CR?- dropping the sync would reduce the resource usage on KLM and API ServerSub issues
The text was updated successfully, but these errors were encountered: