Closed jordojordo closed 3 months ago
Hi, I noticed few issues:
App Version: v1.11.0
App Upgrade: v1.12.0 - Controller: 2.0.11
App Upgrade: v1.12.0 - Defaults: 2.0.0
I found better explanation in our docs:
1. Stack version compatibility among components (https://docs.kubewarden.io/reference/upgrade-path#stack-version-compatibility-among-components)
kubewarden-crds chart, kubewarden-controller chart, kubewarden-defaults chart, any manually deployed policy-server image, and kwctl should run the same MAJOR/MINOR. The PATCH version can increase independently though.
Therefore, if the kubewarden-controller version running is 1.1.x, the policy-servers and kwctl version in use should be 1.1.x as well.
2. Upgrade order (https://docs.kubewarden.io/reference/upgrade-path#upgrade-order)
Kuberwarden users should upgrade the stack starting with the kubewarden-crds chart, then the kubewarden-controller chart. After that, upgrade the policy-server (via kubewarden-defaults chart or bumping the images of custom ones) and kwctl.
Buttons don't follow those rules:
@kravciak I've updated the defaults chart upgrade button to only be shown when it is compatible with the installed controller chart. But this leads me to a thought, should we limit the ability to update the controller chart when the defaults chart hasn't been upgraded to match the installed version of the controller?
As for the mouse cursor not updating when hovering over the buttons, I do not see this behavior, could you take a video?
Here's a set of app upgrades:
app version v1.10.0
with defaults upgrade available
app version v1.10.0
after defaults upgrade
app version v1.11.0
with defaults upgrade available
app version v1.11.0
after defaults upgrade
app version v1.12.0
with defaults upgrade available
About hidden defaults upgrade - it was a bit confusing for me at first try, I just did 1.12 update and there is another 1.12 update. If I didn't know what's happening it's easy to miss that first was controller and second defaults. Just a preference...
@kravciak But this leads me to a thought, should we limit the ability to update the controller chart when the defaults chart hasn't been upgraded to match the installed version of the controller?
We should discuss about hiding controller upgrade on daily, I am not sure.
As for the mouse cursor not updating when hovering over the buttons, I do not see this behavior, could you take a video?
It's quite strange, when I start recording cursor is fixed (but only during recording :)) ...maybe I can screen-share it when you are online?
I removed the upgrade button for the controller chart when the versions are out of sync. There will be a banner displayed informing the user that the defaults chart must be updated to match the appVersion of the controller chart.
appVersion mismatch
appVersion satisfied
The issue was caused by an undefined version in the getValidUpgrade
method. I added an extra condition in the beginning to exit the method when either currentVersion
or upgradeVersion
are undefined.
Also I fixed the pre-release check in the appVersionSatisfies
method to use the pre-release setting.
If the users are out of sync with an old defaults, the upgrade button should install defaults step by step to be in accordance with our upgrade strategy.
Fix #655 Fix #700
This adds a upgrade button for the
kubewarden-defaults
chart on the Dashboard view. Refactored a few things to reuse the functions used to determine if an upgrade is available for the controller for a more agnostic approach. Also fixed the alignment of the badges.With upgradable controller and defaults chart
With only upgradable defaults