CORENET-6055: Dockerfile: Unpin OVN and consume the latest from FDP. #2721
Conversation
OVN-Kubernetes is always lagging behind on the version of OVN it pins. This is causing a lot of trouble with keeping up with bug fixes and especially CVE fixes on older branches, resulting in scanners flagging this image with poor security grades and much longer time for bug fixes to be delivered to customers as the PR backporting process can take weeks or even months. Removing the pin, so every time the new build is released in FDP, it automatically gets into versions of OpneShift that use it. There is a pre-release testing process in place between FDP and OCP QE that ensures the required test coverage before the new build is released through FDP. Keeping OKD versions separate since sometimes new major versions are not released at the same time in FDP/RHEL and CentOS, so we may need them different at some point in time. Signed-off-by: Ilya Maximets <[email protected]>
openshift-ci-robot
added
the
jira/valid-reference
|
@igsilya: This pull request references CORENET-6055 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 story to target the "4.20.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
The change doesn't affect the version of RPMs being installed, but just in case: |
|
This PR contains no functional chnages, so all the failures are just failures on the current master... |
|
/hold remove hold after 22nd feature freeze for 4.20 - this should land in 4.21 |
openshift-ci
bot
added
the
do-not-merge/hold
|
/test e2e-aws-ovn-fdp-qe |
1 similar comment
|
|
@tssurya I guess we can remove the hold now, right? |
|
OVN FDP CI OCP-83672:anusaxen:SDN:[sig-networking] SDN IPSEC EW [FdpOvnOvs][Skipped Setup] IPSec Functionality check for FDP usecase. [Disruptive] [Serial] fail [github.com/openshift/openshift-tests-private/test/extended/networking/ipsec.go:859]: Interrupted by User OCP-47028:huirwang:SDN:[sig-networking] SDN OVN EgressIP [FdpOvnOvs] After remove EgressIP node tag, EgressIP will failover to other availabel egress nodes. [Serial] error: Failed to update egress node:timed out waiting for the condition |
|
/unhold |
openshift-ci
bot
removed
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: igsilya, martinkennelly 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 |
openshift-ci
bot
added
the
approved
|
@asood-rh can you add the verified label? |
|
/retest |
|
/verified by CI + OVN FDP CI. |
openshift-ci-robot
added
the
verified
|
@asood-rh: This PR has been marked as verified by 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 openshift-eng/jira-lifecycle-plugin repository. |
|
Failures seem not related to the change. |
|
/retest-required |
|
@igsilya CI is a bit challenging for the last two weeks. Theres lots of unrelated issues now especially on aws. |
|
@martinkennelly yeah, |
|
/override ci/prow/lint |
|
@igsilya ill merge this shortly, just want to give the fdp job another run. Its not looking good recently so its probably unrelated to your PR.. |
https://issues.redhat.com/browse/OCPBUGS-60182# < but it doesnt capture the error we see here. I asked the person who originally added the code for this edge-app who maintains it. |
|
@martinkennelly FDP job is also tracked in openshift/release PR. I had marked it verified based on the run that had only two failures. Since then there have been changes to openshift test repo. |
|
/test e2e-aws-ovn-fdp-qe A bunch of tests failed for unknown reasons. Don't think this job is stable enough to make as required. (Unrelated to this PR but proposed on release) |
Ya, this PR is fine with the FDP job after looking at the history. I'll unhold it shortly. |
|
/unhold FDP qe job is too unstable to get a signal. |
openshift-ci
bot
removed
the
do-not-merge/hold
|
It was fine in the run before that except unrelated failure and known failure for ipsec. |
|
@martinkennelly If it is of concern, I will create a cluster with PR image and execute the test, taking CI out of picture. There are couple of CI related PRs out which stabilizes and results in better signal. |
Its OK. I saw a clean run minus known issue with ipsec. Thanks. |
|
/hold Revision 8aa4fb7 was retested 3 times: holding |
openshift-ci
bot
added
the
do-not-merge/hold
|
/retest-required |
|
/override ci/prow/lint |
|
@martinkennelly: Overrode contexts on behalf of martinkennelly: ci/prow/lint 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. |
|
/override ci/prow/4.21-upgrade-from-stable-4.20-e2e-gcp-ovn-rt-upgrade It hit the timeout in the previous run and its an issue thats being addressed here: openshift/release#69287 The job is borked because of flakes and that the job now consistently reaches the timeout. Unrelated to this PR. |
|
@martinkennelly: Overrode contexts on behalf of martinkennelly: ci/prow/4.21-upgrade-from-stable-4.20-e2e-gcp-ovn-rt-upgrade 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. |
|
@igsilya bgp-local-gw is bad recently. It did pass previously on this PR. Ill let it run to completion and take action then later today if it flakes for the reasons Ive seen on other PRs.. Ill try to create bugs for the flakes I am seeing. The toil is intolerable. |
|
/unhold |
openshift-ci
bot
removed
the
do-not-merge/hold
|
FWIW, bgp-local-gw passed this time. But why th re-run of half the jobs was triggered again is beyond my understanding... |
|
@igsilya: The following tests failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
|
/test e2e-aws-ovn-local-to-shared-gateway-mode-migration |
openshift-merge-bot
bot
merged commit 53c8c29
into
openshift:master
|
/cherry-pick release-4.20 |
|
@igsilya: new pull request created: #2808 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. |
6 participants
OVN-Kubernetes is always lagging behind on the version of OVN it pins. This is causing a lot of trouble with keeping up with bug fixes and especially CVE fixes on older branches, resulting in scanners flagging this image with poor security grades and much longer time for bug fixes to be delivered to customers as the PR backporting process can take weeks or even months.
Removing the pin, so every time the new build is released in FDP, it automatically gets into versions of OpneShift that use it. There is a pre-release testing process in place between FDP and OCP QE that ensures the required test coverage before the new build is released through FDP.
Keeping OKD versions separate since sometimes new major versions are not released at the same time in FDP/RHEL and CentOS, so we may need them different at some point in time.
OVN-Kubernetes is currently using the latest OVN builds already, so this PR doesn't actually change anything for the current images. But it will bring newer OVN builds automatically as soon as they are released in the future. Major version upgrades still require a separate PR.