-
Notifications
You must be signed in to change notification settings - Fork 143
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
SDN-5297,SDN-5508: DownStream Merge Sync from 4.18 [12-17-2024] #2400
SDN-5297,SDN-5508: DownStream Merge Sync from 4.18 [12-17-2024] #2400
Conversation
Emit Event if NAD cannot be parsed
OCPBUGS-39157,SDN-4930: Downstream Merge Sept 4th
ensure that user defined networks are using ipfamilies that the cluster supports Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com>
currently the udn/nad primary network e2e testing does nothing to check to state of the cluster before creating the network. This makes it possible to test primary networks with ip families that the underlying cluster does not support which is not possible. This commit ensures that e2e testing will only create primary networks that conform to the cluster being tested Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com>
UDN LGW: ensure masq chain exists before adding rules
Signed-off-by: Enrique Llorente <ellorent@redhat.com>
adding testing using User Defined Network objects to pod2Egress testing and "isolates overlapping CIDRs" tests Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com>
This commit is to add some unit tests to make sure proper NAT entries are being created i NBDB while DisableSNATMultipleGWs is set to true. Signed-off-by: Arnab Ghosh <arnabghosh89@gmail.com>
corrections to user defined networking
Add unit tests for UDN while DS is true
kubevirt, e2e: Use e2enode to label/unlabel
Add a source pod create retry function for egress firewall e2e.
When users attach pod to a secondary network and override the default route pod. It will cause the assymetric routing for service haripin traffic. We add static routes to ensure the traffic to the hairpin masquerade IP always goes to OVN. Signed-off-by: Peng Liu <pliu@redhat.com>
There are some expectation at the dev-env interface at metallb that can change and break ovn-k CI, let's pin it so we can propertly consume those changes at a PR later on. Signed-off-by: Enrique Llorente <ellorent@redhat.com>
kind: Pin metallb to v0.14.8
Test opens a TCP connection that simulates a GCP LB environment where the packet is redirected via iptables to a local server on a node. Note, in GCP the LB does not DNAT the VIP, so the packet arrives to the node with the GCP VIP on it. In OCP, we then redirect that packet to the local kapi server running on the node. Once the test opens the TCP connection, it leaves it open for 2 minutes while ovnkube-node is then deleted. Post ovn-controller starting it should not flush the conntrack in zone 0, and the test ensures that the conntrack entry still exists. Recent OVN regression that prompted this E2E: https://issues.redhat.com/browse/FDP-773 Signed-off-by: Tim Rozet <trozet@redhat.com>
Signed-off-by: Tim Rozet <trozet@redhat.com>
Signed-off-by: Tim Rozet <trozet@redhat.com>
Adds e2e test: conntrack flush after ovnkube delete + bumps OVN with fix
When deploying the kind cluster, in order to allow running VMs with primary-UDN, the kubevirt CR is patched with: - NetworkBindingPlugins feature gate. - the passt network binding Signed-off-by: Ram Lavi <ralavi@redhat.com>
Co-authored-by: Miguel Duarte Barroso <mdbarroso@redhat.com> Signed-off-by: Ram Lavi <ralavi@redhat.com>
Signed-off-by: Ram Lavi <ralavi@redhat.com>
Separating two different installations into different functions. In future commit this will allow deploying kubevirt-ipam separately when needed. Signed-off-by: Ram Lavi <ralavi@redhat.com>
Although they usually deployed together, ipam may sometimes need to be deployed out of band for dev purposes. For this purpose, introducing an opt-out flag that will prevent installing the latest ipam-controller while still installing cert-manager. Signed-off-by: Ram Lavi <ralavi@redhat.com>
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
As a bonus add some coverage to the function that generates the syntetic network selection element we use to request the primary UDN attachment. Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Co-authored-by: Miguel Duarte Barroso <mdbarroso@redhat.com> Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Fix Panic in ClusterManager: Release IDs only for Primary L2 UDNs
SDN-4930: Bump OVN to ovn24.09-24.09.0-33.el9fdp
OCPBUGS-44381: ds merge 11-11-2024
For a crash fix and CVE backports in libreswan Signed-off-by: Zenghui Shi <zshi@redhat.com>
…rry-pick-2375-to-release-4.18 [release-4.18] OCPBUGS-45867: pin libreswan to 4.6-3.el9_0.3
…openshift-4.18-ovn-kubernetes-microshift OCPBUGS-41284: Updating ovn-kubernetes-microshift-container image to be consistent with ART for 4.18
Signed-off-by: Zenghui Shi <zshi@redhat.com>
…rry-pick-2387-to-release-4.18 [release-4.18] OCPBUGS-45952: bump OVS version to 3.4.0-18
…rom-4.18-12-17-2024
@jluhrsen: This pull request references SDN-5297 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 epic to target either version "4.17." or "openshift-4.17.", but it targets "openshift-4.18" instead. This pull request references SDN-5508 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 epic to target the "4.17.z" 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. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: jluhrsen The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test e2e-azure-ovn-upgrade |
/test e2e-metal-ipi-ovn-ipv6-techpreview |
/test 4.17-upgrade-from-stable-4.16-local-gateway-e2e-aws-ovn-upgrade |
/test e2e-aws-ovn-upgrade |
/payload 4.17 ci blocking |
@jluhrsen: trigger 4 job(s) of type blocking for the ci release of OCP 4.17
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/0db64230-bdc5-11ef-96ba-491e62d547a2-0 trigger 9 job(s) of type blocking for the nightly release of OCP 4.17
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/0db64230-bdc5-11ef-96ba-491e62d547a2-1 |
/retest |
These look ok. the ci jobs all passed. the nightly jobs had a couple of failures. nightly-4.17-e2e-aws-ovn-serial failed with something about e2e-azure-ovn-upgrade had a failure I don't know about in fips-payload-scan failed and I have no real idea on this one. asking in slack here. |
@jluhrsen: 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. |
PR needs rebase. 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. |
Looks like something got merged in to 4.17 outside of this sync process. will have to rebase and figure it out. |
it may be easier to just use a new PR with the latest from 4.18. These conflicts are pretty confusing to fix after doing a 'git merge' closing for now and we'll see how the new PR does. |
this supersedes #2349