CORENET-6005: network, virt: graduate preconfigured UDN addresses feature gate #2496
Conversation
Signed-off-by: Miguel Duarte Barroso <[email protected]>
openshift-ci-robot
added
the
jira/valid-reference
|
@maiqueb: This pull request references CORENET-6005 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.21.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. |
|
Hello @maiqueb! Some important instructions when contributing to openshift/api: |
openshift-ci
bot
added
the
size/S
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
|
/jira refresh |
|
@maiqueb: This pull request references CORENET-6005 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 either version "4.21." or "openshift-4.21.", but it targets "openshift-4.20" instead. 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. |
|
/jira refresh |
|
@maiqueb: This pull request references CORENET-6005 which is a valid jira issue. 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. |
|
@maiqueb Is there a reason this is currently only being tested on one variant? |
Hey @JoelSpeed o/ Yes, and a good one - this feature is only supported on bare-metal. Hence, no point in testing it in other platforms. |
|
/retest verify-feature-promotion |
|
@maiqueb: The The following commands are available to trigger optional jobs: Use 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. |
|
/test verify-feature-promotion |
|
@maiqueb: 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. |
|
@maiqueb And its only supported on dual stack? Or also single? |
It should be on all networking configurations. We chose to deploy it only on dual-stack since that configuration is more flexible, and we get to check all types of UDNs in it (single stack IPv4 ; single stack IPv6 ; dual-stack). At the end of the day, that is the "subject" under test. |
|
Could you please also add testing on the two single stack variants, so we have complete coverage? |
@tssurya FYI |
Our QE @asood-rh should be doing v4 and v6 singlestack and dualstack on their side as well - we were trying to have less duplication between devel and qe on platform support resources wise but adding this might also help QE in some sense. So I don't mind having it in our ocp CI (not just qe CI). Although our baremetal CI resources are always limited so for each networking feature we seem to be adding new lanes for each feature level which is going to blow up at some point: Example:
For this feature we did:
In the past for persistentIPs we did:
For L3 live migration @qinqon added a hypershift-kubevirt which always perma fails and not sure if there are periodics for this So +1 for all stack coverage just want to highlight we might need to perm/combo choose a subset or consolidate all VM features into a single lane for cost-save rather than adding a virt lane per feature OR put all bgp features into a single lane |
Testing should default to on the public side of things now. There are various reasons we historically had private QE testing, but for new stuff, we should always aim for public testing reporting into sippy. Without data going into sippy we cannot manage regressions across the product.
Are there ways that the same clusters can be used to test these various features serially, so that we don't spin up a new suite for every feature? |
|
@JoelSpeed so we need 4 new lanes right ? 2 (TP and GA) for single stack ipv4; same for ipv6 |
@maiqueb That sounds correct. |
ack that's good to know! Is this also captured on our FG docs?
yes I believe its possible to consolidate instead of doing a new job per feature. |
|
@JoelSpeed in hindsight, we've just realized this feature is not supposed to work for IPv6 single stack clusters. It is clearly listed in the merged openshift enhancement: https://github.com/openshift/enhancements/pull/1793/files#diff-68747e5623b9c43b40b99e813c2acd3d642f58de610cfac6025699c66f062eeaR106 Thus, I think we should only add single stack IPv4 lanes. Would that be OK ? |
+1 |
To clarify further - that means the usage of this feature is unsupported in that environment? How are we planning to make customers aware of that? If the feature is attempted to be used in an IPv6 single stack cluster, what happens? |
It won't work. The feature is initiated from MTV (which imports the VM from the vmware cluster), which is not ipv6 aware. |
Sounds fine to me to drop that testing lane if it is known to not work and customers will be made aware of the fact the feature doesn't support the ipv6 single network stack. |
No description provided.