Backporting commits to the release-2.5 branch #1204
Merged
+280
−136
Conversation
This file contains hidden or 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
Currently we have only one "ready" label to signify that the kernel module is loaded successfuly. In order upgrade scenario, the user needs to know that the loaded module is actually the one with the targeted module version, in order to coordinated further actions. This PR introduces a new label: kmm.node.kubernetes.io/%s.%s.version.ready, whose value will signify the version of the currently loaded kernel module. The changes in the code are: 1. Adding Version field both to status and spec of NMC (will be used to construct the new label) 2. Polulating the Version field of the NCM's spec during NMC update/create 3. Adding the "version" annotation to the worker pod, so that the version may be extracted for NMC's status 4. Changing the Node package API to receive maps instead of slice for labels to be added/remove. This is done since now we must also update the value of the label, and not just the key 5. Rewrite the UpdateNodeLabel function in the NMC controller to support new flow and new Node API 6. In case "ready" label is removed, we also automaticaly remove "version.ready" label. If it does not exists - nothing happens 7. In case "ready" label needs to be added, we check if the version field exists in the NMC status, and if it does, then we add the "version.ready" label with appropriate value
Users need an official API to determine if their kmod was upgraded to the newer version successfully when using the ordered-upgrade flow. Before this commit, we only had a label describing if a specific kmod is ready to be used or not but the same label was used for all versions. To prevent users from watching the ready label being removed and then re-appearing for the new kmod, we decided to add a new label with the kmod version in it. Signed-off-by: Yoni Bettan <[email protected]>
In case node becomes unschedulable (cordon, taint wihtout toleration etc'), the kmod ready version is removed. In addition, the kmod version ready label should also be removed. We do it unconditionally, since the action does not produce error even if the label does not exists on the node
When building the bundle locally we usually use `make bundle` but when building it in cloudbuild for publishing in operatorhub.io, we use `make bundle ... USE_IMAGEDIGESTS=true` which will eventually generate the manifests and run `operator-sdk generate bundle ... --use-image-digests`. While the main purpose of this flag is to refer all images by digest, it also, as a side effect, pull those images to discover their digest. Since we are using dummy images in the CSV samples, with a "real" image URL, operator-sdk treats those as actual pullable images, and tries to pull them to discover their digest. This commit is changing the dummy images with a "place holder description" instead of a valuable URL to prevent `operator-sdk` treating those as real images. Signed-off-by: Yoni Bettan <[email protected]>
Signed-off-by: Yoni Bettan <[email protected]>
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ybettan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
approved
Contributor
Author
|
/override pull-kernel-module-management-check-commits-count |
Contributor
|
@ybettan: Overrode contexts on behalf of ybettan: pull-kernel-module-management-check-commits-count In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Contributor
|
/lgtm |
k8s-ci-robot
added
the
lgtm
adding public API that can be used by KMM's user: 1. API to get the module version label format 2. API to get the module version ready label format
k8s-ci-robot
removed
the
lgtm
Contributor
Author
|
/override pull-kernel-module-management-check-commits-count |
Contributor
|
@ybettan: Overrode contexts on behalf of ybettan: pull-kernel-module-management-check-commits-count In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Contributor
|
/lgtm |
k8s-ci-robot
added
the
lgtm
k8s-ci-robot
merged commit b765898
into
kubernetes-sigs:release-2.5
24 of 25 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
/assign @yevgeny-shnaidman @TomerNewman