USHIFT-5818: Generic Device Plugin - Sanity Smoke Test#5121
USHIFT-5818: Generic Device Plugin - Sanity Smoke Test#5121openshift-merge-bot[bot] merged 3 commits intoopenshift:mainfrom
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@pmtk: This pull request references USHIFT-5818 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.20.0" version, but no target version was set. DetailsIn 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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
Bot
added
the
approved
pmtk
force-pushed
the
gen-dev-plug/rf-test
branch
from
08c436f to
62d3191
Compare
There was a problem hiding this comment.
Do you think we should use uname -r / pass one single kernel if there is more than one being listed ? if the system has more than one kernel i see this command is failing.
There was a problem hiding this comment.
We cannot use uname -r because it returns the kernel of the host, bootc container can (and had when I tested it) contain different kernel.
It's true that rpm -q --qf will return all matching pkgs, but the problem is that what you're running might not be the newest one.
Because these commands are inside containerfile, not really reusable automatically (by importing a file) anywhere else, I would recommend that for QE testing you can copy and tweak them to your needs.
There was a problem hiding this comment.
This is not clear for me. Containers are using kernel of the host, aren't they?
What would happen if the kernel in the container is different from the kernel on the host (majority of cases)?
Should we install both the kernel and the kernel-devel of the host?
There was a problem hiding this comment.
Yes, containers are using kernel from the host and that's why there's a difference between uname -m and version returned by rpm.
There's already a kernel installed in the base bootc image, so I decided to install matching kernel-devel (rather to upgrade kernel and install kernel-devel). The kernel in the image is not active when building an image, but it will be when the image is installed onto the disk.
Personally, I wouldn't attempt to install the kernel of the host because there's no guarantee what someone has on their hypervisor (maybe it's older one). I feel like keeping the kernel might be easier if there's some kind of bug to report (I mean: image tag is pointing to kernel we're not changing).
Though maybe there's value in upgrading the kernel, so we can do it.
WDYT?
There was a problem hiding this comment.
Let's think what users would do in this case. Wouldn't they likely try to sync the kernel version between the host and the container?
There was a problem hiding this comment.
What would they get by syncing the, for examples, CI's host kernel with the kernel of the image that will be installed on another host? At most, I would expect them to run dnf upgrade to get latest packages (including kernel).
I feel like this discussion is out of scope for this PR - current solution works and is completely valid: it installs kernel-devel for kernel already included in the bootc image, then compiles a driver for that particular kernel, there's no runtime involved, so there's no need to involve host's kernel.
Whether we should upgrade all packages or match kernel versions if more of a testing approach question and is, imho, applicable to all images we build (like, let's take rhel96-bootc-source image for example, question of upgrading the pkgs and/or kernel is just as valid).
There was a problem hiding this comment.
OK, we can continue this interesting discussion elsewhere.
I'll approve the PR for now.
pmtk
force-pushed
the
gen-dev-plug/rf-test
branch
2 times, most recently
from
b58d89d to
7c243d7
Compare
pmtk
force-pushed
the
gen-dev-plug/rf-test
branch
from
7c243d7 to
0036578
Compare
|
/test e2e-aws-tests-bootc |
pmtk
force-pushed
the
gen-dev-plug/rf-test
branch
from
3983070 to
228222f
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ggiguash, pmtk The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
|
/test e2e-aws-tests-bootc-arm |
|
@pmtk: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
5 participants
No description provided.