UDN: Add managedTap binding support to Kubevirt CR #3139
Conversation
|
Skipping CI for Draft Pull Request. |
1 similar comment
|
Skipping CI for Draft Pull Request. |
kubevirt-bot
added
do-not-merge/work-in-progress
kubevirt-bot
added
size/S
release-note-none
Pull Request Test Coverage Report for Build 12063553262Details
💛 - Coveralls |
kubevirt-bot
removed
the
do-not-merge/work-in-progress
kubevirt-bot
added
release-note
|
hco-e2e-upgrade-operator-sdk-aws lane succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-upgrade-operator-sdk-azure, ci/prow/hco-e2e-upgrade-prev-operator-sdk-azure 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. |
|
hco-e2e-upgrade-prev-operator-sdk-sno-aws lane succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-operator-sdk-aws, ci/prow/hco-e2e-upgrade-prev-operator-sdk-sno-azure 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. |
|
addressed comments, ptal |
|
Going to create a new PR doing the opposite, so the userDefinedPrimaryNetworkBinding will point to managedTap, we can test later on passt by installing HCO using the json capababilities so we patch the binding and change from managedTap to passt, no need for new binding. |
controllers/operands/kubevirt.go
Outdated
| primaryUDNNetworkBindingName = "passt" | ||
| managedTapUDNNetworkBindingName = "managedTap" |
There was a problem hiding this comment.
I was wrong, we should change the primaryUDNNetworkBindingName to managedTap, if we want to test passt we just use HCO json patching for kubevirt CR and create manually the NAD, at the end is a development workflow.
Also keeping the same name for the binding is important from the beginning so we don't have to modify VM/VMI to upgrade from managedTap to passt
There was a problem hiding this comment.
We can rename vars here but dont need to drop old passt support atm,
the CR can hold both and it will allow smoother QE adaption
same for NAD on CNAO and all, cleaning will be on a follow-up according needs
for now we just need to think about the generic name (unless this also can be done in phases)
lets continue please the design that was started offline
There was a problem hiding this comment.
switched the primary one to be managedTap
renamed it to have generic name defaultPodNetworkBinding
update PR desc on how it should look (but didnt test yet, will do once we are in sync, and then will update all the other relevant PRs)
|
TODO - need first to add |
oshoval
changed the title
kubevirt-bot
removed
the
do-not-merge/work-in-progress
|
| @@ -2059,7 +2059,8 @@ Version: 1.2.3`) | |||
| }, | |||
| }, | |||
| } | |||
| Expect(existingResource.Spec.Configuration.NetworkConfiguration.Binding[primaryUDNNetworkBindingName]).To(Equal(expectedInterfaceBindingPlugin)) | |||
| Expect(existingResource.Spec.Configuration.NetworkConfiguration.Binding).To(HaveKeyWithValue(primaryUDNNetworkBindingName, primaryUserDefinedNetworkBinding())) | |||
There was a problem hiding this comment.
Please consider instantiating an expected value for the l2bridge, similar to what was done for passt, as currently the unit test is not independent.
There was a problem hiding this comment.
imo it is fine like that, the function is simple and doesn't even gets parameters
it allows to change just one place and i don't see it reduce safety in a way that make this change required
There was a problem hiding this comment.
Another point is that is forces the reviewer of the test to look at the implementation details of primaryUserDefinedNetworkBinding in order to understand what is actually done.
There was a problem hiding this comment.
otoh it hides details, and allow him to look just if he need to
each side has pros (for example DRY principal) and cons, here imo it isn't code that prone for errors so it doesnt worth to be extra safe
|
hco-e2e-consecutive-operator-sdk-upgrades-aws lane succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-consecutive-operator-sdk-upgrades-azure, ci/prow/hco-e2e-upgrade-prev-operator-sdk-azure 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. |
|
hco-e2e-upgrade-operator-sdk-sno-azure lane succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-upgrade-operator-sdk-sno-aws 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 ci/prow/hco-e2e-operator-sdk-aws per request, but it doesnt seem at all this PR is related |
|
hco-e2e-kv-smoke-gcp lane passed |
|
@oshoval: The specified target(s) for 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. |
|
@oshoval: The specified target(s) for
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. |
|
@nunnatsa: Overrode contexts on behalf of nunnatsa: ci/prow/hco-e2e-kv-smoke-azure 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. |
|
@openshift-ci[bot]: The specified target(s) for
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. |
|
/retest |
|
hco-e2e-operator-sdk-gcp lane succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-operator-sdk-aws, ci/prow/hco-e2e-operator-sdk-azure 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. |
|
@oshoval: 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. |
|
hco-e2e-operator-sdk-aws, hco-e2e-operator-sdk-gcp lanes succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-operator-sdk-azure 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. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nunnatsa 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 |
kubevirt-bot
added
the
approved
What this PR does / why we need it:
Kubevirt introduce new binding for seamless migration.
kubevirt/kubevirt#13024
This PR adds support to it via the Kubevirt CR in addition to Passt support
(under
primaryUserDefinedNetworkBindingFG).After enabling the required FG
kubectl patch hco -n kubevirt-hyperconverged kubevirt-hyperconverged --type=json -p='[{"op":"replace","path":"/spec/featureGates/primaryUserDefinedNetworkBinding","value":true}]'oc get kubevirts -n kubevirt-hyperconverged kubevirt-kubevirt-hyperconverged -oyamlshows:Reviewer Checklist
Jira Ticket:
Release note: