Bug 1829517 - hardcoded ens3 in cluster-network-operator kuryr config causes failure on ppc64le
Summary: hardcoded ens3 in cluster-network-operator kuryr config causes failure on ppc...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.4
Hardware: ppc64le
OS: Unspecified
Target Milestone: ---
: 4.6.0
Assignee: Michał Dulko
QA Contact: GenadiC
Whiteboard: multi-arch
Depends On:
Blocks: 1593829 1593825 1855773
TreeView+ depends on / blocked
Reported: 2020-04-29 17:03 UTC by Jeremy Freudberg
Modified: 2020-10-27 15:58 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: Kuryr-Kubernetes will now attempt to detect the bridge interface for the pod subports on the CNI level, instead of just using a value set in kuryr.conf (and in OpenShift effectively hardcoded to "ens3"). Reason: This is to support cases when VMs call the interface differently. Result: kuryr-daemon will look for the configuration option first. If it's not set or configured interface is not present on the VM, it will try to figure out on which interface kubelet is listening on and use it as bridge interface. If that won't be possible it'll just choose first non-loopback interface on the VM.
Clone Of:
: 1855773 (view as bug list)
Last Closed: 2020-10-27 15:58:32 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift kuryr-kubernetes pull 299 0 None closed Bug 1829517: Attempt to autodetect interface in nested setups 2021-02-08 22:10:56 UTC
Red Hat Product Errata RHBA-2020:4196 0 None None None 2020-10-27 15:58:56 UTC

Description Jeremy Freudberg 2020-04-29 17:03:16 UTC
The interface ens3 is hardcoded in cluster-network-operator kuryr config
(See https://github.com/openshift/cluster-network-operator/commit/b961d7ad086f942a0f84472378909f81e5802dea)

In a virtual machine on ppc64le, this is almost definitely wrong.

For example, in my ppc64le environment, it needs to be enp0s1 instead.

Could we autodetect?
Or, could we let the user specify?

Comment 5 Jon Uriarte 2020-07-17 10:53:02 UTC
Verified in 4.6.0-0.nightly-2020-07-16-005008 on top of OSP 13 2020-07-09.1 puddle.

As we don't have access to a ppc64 platform it's been verified by changing the default value 'ens3'
by a non-existent interface name in kuryr.conf. This way we simulate the case in which the VM doesn't
have an interface name with the default value, and the interface name will be discovered.


1. Scale down the network operator to 0, so the kuryr config map is not rewritten with the default config
after manually changing the config map.
$ oc -n openshift-network-operator scale --replicas=0 deployment/network-operator

2. Change the default link_iface value in kuryr config map:
$ oc -n openshift-kuryr edit cm kuryr-config
-     link_iface = ens3
+     link_iface = eth0

3. Restart the kuryr cni pods in order to take the new configuration
4. Create a new pod and check it's correctly attached to the interface, the next log is shown in kuryr cni:
Using kubelet bind interface ens3 as bridge interface.

Comment 7 errata-xmlrpc 2020-10-27 15:58:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.