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

Track upgrade status in UI #433

Open
davidcassany opened this issue Apr 27, 2023 · 2 comments
Open

Track upgrade status in UI #433

davidcassany opened this issue Apr 27, 2023 · 2 comments
Labels
area/ui area/upgrade kind/enhancement New feature or request spike Some research required
Milestone

Comments

@davidcassany
Copy link
Contributor

davidcassany commented Apr 27, 2023

This card is about tracking the status of the upgrade group somewhere within the UI, which basically results in keep some sort of status of it in ManagedOSImage or any other related resource.

See #364 (comment) for some comments around this. Basically the issue is relating the system-upgrade-controller plans (in downstream cluster) up to fleet-bundle (in upstream cluster).

The proper solution would be finding a way to gather from the fleet bundle resource (in upstream cluster and related to a ManagedOSImage instance) all bundle deployments (one per cluster in downstream clusters), then from the bundle deployment find a way to gather and track the system-upgrade-controller plans. I believe the hardest part is achieving a meaningful status monitoring between fleet and system-upgrade-controller.

An alternative could be to code some naive logic on top of all this, like elemental-operator marks all nodes pending to be upgraded once an upgrade group is created. The problem of such an approach is that we would have to replicate fleet selector logic in elemental-operator.

A third idea could be tracking status on nodes individually, aka track the start and the ending of a particular node upgrade without a cluster vision. I guess this could be somehow coded as part of the upgrade plan by extending/reusing the elemental-register to annotate the machineinventory when the upgrade starts and similarly annotate when the upgrade is done (with success or failure).

@davidcassany davidcassany added area/upgrade spike Some research required labels Apr 27, 2023
@fgiudici
Copy link
Member

Issue #434 could be part of the foundation to track the current provisioning state (OS, cluster association, etc.).

@Martin-Weiss
Copy link

+100 - managing OS versions / patchlevel is key in Elemental (at least from my point of view)

So - we need an overview "what is running where" and we need a rollout management and error handling for assiginging when should which server/node be upgraded / downgraded and we need to see the process of this.

The UI needs to reflect the progress and status and maybe even an estimation for when it might be completed.
We also might need a "cancel" button.

This also needs some sort of support for disconnected scenarios / single node clusters scenarios.

And we need some sort of reporting "this node has these CVEs and needs upgrade".

@kkaempf kkaempf modified the milestones: 2024-Q1-v2.8x, Micro6.1 Mar 19, 2024
@kkaempf kkaempf modified the milestones: Micro6.1, Micro6.2 Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ui area/upgrade kind/enhancement New feature or request spike Some research required
Projects
Status: 💡 Backlog
Development

No branches or pull requests

4 participants