Bug 1816971
Summary: | kubemacpool-mac-controller-manager rejects network with ips as an array | ||
---|---|---|---|
Product: | Container Native Virtualization (CNV) | Reporter: | Matthew Booth <mbooth> |
Component: | Networking | Assignee: | Petr Horáček <phoracek> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Yan Du <yadu> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 2.3.0 | CC: | aburden, aspauldi, cnv-qe-bugs, fpan, fsimonce, lmandavi, mschuppe, myakove, ncredi, phoracek, royoung, stirabos, tohayash, weliang |
Target Milestone: | --- | Flags: | aspauldi:
needinfo+
|
Target Release: | 2.3.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | hyperconverged-cluster-operator-container-v2.3.0-61 - hco-bundle-registry-container-v2.3.0-159 | Doc Type: | Removed functionality |
Doc Text: |
Due to a bug, KubeMacPool was disabled in CNV 2.3. With the absence of the component, secondary interfaces of Pods and VMs will not be given a MAC address from a pool. Instead, in case the user does not specify an explicit MAC address to use, they will obtain a randomly generated address. This means that in some really rare occurrences, there may be conflicts in assigned MAC addresses.
|
Story Points: | --- |
Clone Of: | 1816746 | Environment: | |
Last Closed: | 2020-05-06 11:14:28 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1816746 | ||
Bug Blocks: |
Description
Matthew Booth
2020-03-25 10:00:55 UTC
(In reply to Tomofumi Hayashi from comment #1) > Upstream PR: > https://github.com/k8snetworkplumbingwg/net-attach-def-admission-controller/ > pull/39 Sorry, it is not for the bz.... @Meni, could you please verify that we are able to create a VM with secondary network on 2.3 with KubeMacPool involved? I'm afraid this may be a blocker for 2.3. Just found out this issue happens only when IPAM is used for the secondary network. IPAM is not documented in our docs AFAIK and we recommend using basic L2 and handle addressing via a DHCP server running on the network. But since we reconcile Pods too, it affect all the workload. I suggest this as a blocker. We will resolve it simply by disabling the webhook on Pods. Since we don't keep Webhook configuration in CNAO, but it is generated by KMP, we need to change the sources of KMP itself and backport it. Petr, all our secondary networks use mac pool (by default). We don't set IPEM. Thanks. The issue seems to affect only Pods/VMs using IPAM. We have to fix it not to break secondary networks on Pods in OpenShift. Since it is so late in the release cycle, we are disabling KMP in 2.3. Docs impact is a Known Issue in the 2.3 Release Notes. PR: https://github.com/openshift/openshift-docs/pull/21431 @Nelly, can you please assign someone to QE review? LGTM but since i dont see the genreated doc, i cant tell if {CNVProductName}& {CNVVersion} params are properly working (no other known issues use them) Meni, could you please test upgrade from 2.2 to 2.3 and make sure that KMP is removed during it. After upgrade the cluster from OCP4.3+CNV2.2 to OCP4.4+CNV2.3, the KMP is not existing anymore. Adjusted the doc text to make it clear that this issue only affects VMs that don't have an explicit MAC address set. This bug was listed under Known Issues for the CNV 2.3 release. I am noting that it was closed for the current release. Therefore, I am deleting this write-up from the Known Issues section of the CNV 2.4 release for this defect [lmandavi] |