-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for platform-alteration-base-image test case. #1861
Fix for platform-alteration-base-image test case. #1861
Conversation
The original workaround to use a custom podman for this test case stopped working when we switched our debug pod's image from ubi8 to ubi9 due to libc missing in RHEL8.x based nodes (OCP 4.12.z and lower). This pre-built podman binary was used in this tc no matter the OCP version of the cluster. This commit will make the test case to use our ubi8-based podman only if the test suite is checking CNFs on OCPs 4.12.z or lower. For newer versions of OCP, the podman that's presinstalled in the nodes will be used, as it seems to work well again. We should remove this ugly workaround when 4.12 reaches EOL. The fix to build podman with ubi8 again is already merged in the partner repo here: redhat-best-practices-for-k8s/certsuite-sample-workload#394
from change #1861: |
The UT that test the folder creation/mount issues of podman need OCP ver 4.12 or lower to run.
from change #1861: |
check dallas ocp-4.12-vanilla tnf-test-cnf tnf-test-cnf:ansible_extravars=test_network_function_version=HEAD |
Added the do-not-merge label because I'd like to get green light from DCI job on 4.12 before merging it. |
Regarding this: |
@edcdavid that might solve the issue of podman not finding the right libc version, but libc versions are usually quite linked to the running kernel/shared libs versions. Running podman using a RHEL9.x (statically linked) libc in a RHEL8.x's kernel and libs which were compiled with a different libc version might cause some weird compatiblity issues. It doesn't look like a safe move to me, it's not worth the risk. Apart from that, the ideal scenario is not needing any other podman but the one that's already preinstalled in the nodes, which will happen when 4.12 is EOL. |
Please do not merge, the job didn't run the test correctly, I need to re-run it. |
from change #1861: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test is passing now: https://www.distributed-ci.io/jobs/d44597cb-9694-447e-a6d8-a2faa3e12e2f/tests/b80be7a3-a76f-4858-a547-8ff9666a0599
@greyerof feel free to merge this, thanks!
from change #1861: |
from change #1861: |
The original workaround to use a custom podman for this test case stopped working when we switched our debug pod's container image from ubi8 to ubi9 due to libc missing in RHEL8.x based nodes (OCP 4.12.z and lower). This pre-built podman binary was used in this tc no matter the OCP version of the cluster.
This change will make the test case to use our ubi8-based podman only if the test suite is checking CNFs on OCPs 4.12.z or lower. For newer versions of OCP, the podman that's presinstalled in the nodes will be used, as it seems to work well again. I've tested it with SNOs 4.12, 4.13 and 4.14.
We should remove this ugly workaround when 4.12 reaches EOL.
The fix to build podman with ubi8 again is already merged in the partner repo here:
redhat-best-practices-for-k8s/certsuite-sample-workload#394
Also, I changed some logs to use the check's logger.