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

Separate business and module statuses #1471

Closed
1 task done
Tracked by #18450
janmedrek opened this issue Apr 15, 2024 · 4 comments · Fixed by #1628
Closed
1 task done
Tracked by #18450

Separate business and module statuses #1471

janmedrek opened this issue Apr 15, 2024 · 4 comments · Fixed by #1628
Assignees
Labels
API Denotes that an issue is tied to the potential change of the API Epic

Comments

@janmedrek
Copy link
Contributor

janmedrek commented Apr 15, 2024

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

  • Describe the Kyma CR State
    • Given a Kyma Module
      • And a SKR Kyma CR is created on the SKR Cluster
      • And a Module CR is created on the SKR Cluster
      • And a Manifest CR is created on the KCP Cluster
    • When the Kyma Module is enabled
      • Then the Manifest CR is in corresponding state
        • And the Kyma CR Status contains information on all the Kyma Modules enabled in the cluster
          • And the Kyma CR Status contains information on the health of Module Manifest deployment
          • And the Kyma CR Status contains information on all the actions performed on the Module Manifest
            • And it is visible when the Kyma Module was enabled
            • And it is visible when the last Kyma Module upgrade was performed
            • And all the events related to the Module Manifest are visible
        • And the Module CR can have any business state set by the Module Operator
        • And the overall state of SKR Kyma CR is an aggregation of manifest states of modules enabled in the SKR Cluster

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)?

    • consider changing state to something like manifestState
  • 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 fine

  • Should we keep both states in Kyma CR? - dropping the sync would reduce the resource usage on KLM and API Server

Sub issues

@janmedrek janmedrek added Epic API Denotes that an issue is tied to the potential change of the API labels Apr 15, 2024
@ebensom
Copy link
Member

ebensom commented Apr 23, 2024

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.

@janmedrek
Copy link
Contributor Author

Thanks, @ebensom! Will make sure you are involved in the discussions regarding all the API changes.

@jeremyharisch
Copy link
Contributor

jeremyharisch commented May 8, 2024

Acceptance Criteria for EPIC:

  • Research about the topic
  • Think about a proper issue split for this EPIC
  • Create Sub-Issues to cover the implementation
  • Regarding business requirements talk to @janmedrek if needed

Timebox: 2 Days

@ruanxin
Copy link
Contributor

ruanxin commented May 16, 2024

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 Epic
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants