cli: add upgrade-check command #1109
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
derpsteb
force-pushed
the
feat/upgrade-check
branch
6 times, most recently
from
4f59e9d
to
5dc4d43
Compare
datosh
reviewed
Feb 2, 2023
3u13r
requested changes
Feb 2, 2023
Comment on lines
102
to
109
| // currently supported versions. | ||
| //nolint:revive | ||
| V1_24 ValidK8sVersion = "1.24" | ||
| V1_24 ValidK8sVersion = "v1.24.9" | ||
| //nolint:revive | ||
| V1_25 ValidK8sVersion = "1.25" | ||
| V1_25 ValidK8sVersion = "v1.25.6" | ||
| //nolint:revive | ||
| V1_26 ValidK8sVersion = "1.26" | ||
| V1_26 ValidK8sVersion = "v1.26.1" | ||
|
|
There was a problem hiding this comment.
Checked our code again, if I understand it correctly the V1_X ValidK8sVersion variables are only used to keep track of the minor Kubernetes version supported by Constellation (We don't support choosing patch versions).
I think we should keep them as only Major.Minor, not sure about the v prefix.
There was a problem hiding this comment.
The reason for switching to exposing the patch version is that we might want to offer a patch-version upgrade to the user. I think its cleaner to show users that the version will change from e.g. 1.25.6 to 1.25.7 instead of doing this implicitly. Users will still not be able to chose arbitrary patch versions, but it will be obvious which one is running/upgraded.
daniel-weisse
approved these changes
Feb 7, 2023
Version validation checks that the configured versions are not more than one minor version below the CLI's version. The validation can be disabled using --force. This is necessary for now during development as the CLI does not have a prerelease version, as our images do.
derpsteb
force-pushed
the
feat/upgrade-check
branch
from
88a5ef4
to
97f2817
Compare
datosh
approved these changes
Feb 7, 2023
3u13r
approved these changes
Feb 8, 2023
Upgrade check is used to find updates for the current cluster. Optionally the found upgrades can be persisted to the config for consumption by the upgrade-execute cmd. The old `upgrade execute` in this commit does not work with the new `upgrade plan`. The current versions are read from the cluster. Supported versions are read from the cli and the versionsapi. Adds a new config field MicroserviceVersion that will be used by `upgrade execute` to update the service versions. The field is optional until 2.7 A deprecation warning for the upgrade key is printed during config validation. Kubernetes versions now specify the patch version to make it explicit for users if an upgrade changes the k8s version.
derpsteb
force-pushed
the
feat/upgrade-check
branch
from
9191219
to
b0cd065
Compare
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed change(s)
constellation upgrade checkas a command and removeconstellation upgrade plan. Upgrade check shows the smallest upgrade a user could do to the current cluster with their current CLI. Smallest since we have to make some decision on which upgrade to show in order to support the--write-configflag. We could add a--allflag to show all possible upgrades.--write-configflag can be used to persist the suggested update into the config.--refand--streamflag to select the ref and stream which should be checked for image upgrades.--forceflag that disables config validation.MicroserviceVersion. This specifies the version of theconstellation-serviceschart and (implicitly) the version of theconstellation-operatorschart. I decided to make the operator version implicit as we would otherwise have to have another config value for it. We could think about unifying the operators and services charts. I don't think there is a technical reason for keeping them separate.Checklist