Allow any version of k8s-client for skuba-update and allow cri-o bump during stage1 #1227
Conversation
|
lgtm ! |
|
Retriggering, as kubernetes was not properly built in the repo when this PR was up. |
| @@ -60,7 +60,7 @@ Summary: Utility to automatically refresh and update a skuba cluster | |||
| Group: System/Management | |||
| Requires: python3-setuptools | |||
| Requires: zypper >= 1.14.15 | |||
| Requires: kubernetes-client | |||
There was a problem hiding this comment.
To prevent the upgrade of the client without reason, we should not do this.
Instead we should remove the requirement, and be explicit about possible breakages.
There was a problem hiding this comment.
If the removal breaks the greenfields's skuba-update (which I doubt we have test coverage for), then we can probably iterate with Requires: (kubernetes-client or k8s-client)
There was a problem hiding this comment.
The Requires of (kubernetes-client or k8s-client) triggers the install of kubernetes-1.18-client during zypper dup, so I removed this require.
|
Please hold. Don't merge this yet. |
With the change of the virtual provides from kubernetes- to k8s- and the version appended packages, we can now to decide whether this package need _any_ version of a kubernetes, or a specific one. skuba-update can rely on any version of kubectl, therefore we should be updating the spec to rely on k8s-client possibly being present.
evrardjp
force-pushed
the
update-virtual-provides-to-k8s
branch
from
a5ce53e to
fd59c96
Compare
evrardjp
changed the title
Without this patch, the removal of kubernetes-kubeadm will be problematic, as no packages will provide it and it is still required by cri-o-kubeadm-criconfig. If we remove this package, and upgrade cri-o to 1.18 during the same transaction, we'll keep the kubelet to the current version, and kubeadm can be upgraded to 1.18.
evrardjp
force-pushed
the
update-virtual-provides-to-k8s
branch
from
fd59c96 to
0e0c8e4
Compare
| // package to avoid upgrade during zypper migration). | ||
| // we need to remove cri-o in stage2 else 1.17 kubelet could | ||
| // complain about cri-runtime being absent. | ||
| pkgs = append(pkgs, "-patterns-caasp-Node-1.17", "-\"kubernetes-kubeadm<1.18\"", "-caasp-config", "-cri-o-kubeadm-criconfig") |
There was a problem hiding this comment.
oh I didn't know zypper was capable to understand a syntax such as -kubernetes-kubeadm<1.18 😉
There was a problem hiding this comment.
With the change of the virtual provides from kubernetes- to
k8s- and the version appended packages, we can now to decide
whether this package need any version of a kubernetes, or
a specific one. skuba-update can rely on any version of kubectl,
therefore we should be updating the spec to rely on k8s-client
being present.
Why is this PR needed?
Without this whole virtual provides, the migration will auto bump k8s to 1.18, which we want to avoid.
What does this PR do?
Ensure we are not using kubernetes-component* packages.
Anything else a reviewer needs to know?
Special test cases, manual steps, links to resources or anything else that could be helpful to the reviewer.
Info for QA
This is info for QA so that they can validate this. This is mandatory if this PR fixes a bug.
If this is a new feature, a good description in "What does this PR do" may be enough.
Related info
Info that can be relevant for QA:
Status BEFORE applying the patch
How can we reproduce the issue? How can we see this issue? Please provide the steps and the prove
this issue is not fixed.
Status AFTER applying the patch
How can we validate this issue is fixed? Please provide the steps and the prove this issue is fixed.
Docs
If docs need to be updated, please add a link to a PR to https://github.com/SUSE/doc-caasp.
At the time of creating the issue, this PR can be work in progress (set its title to [WIP]),
but the documentation needs to be finalized before the PR can be merged.
Merge restrictions
(Please do not edit this)
We are in v4-maintenance phase, so we will restrict what can be merged to prevent unexpected surprises: