Bug 1513768 - [3.6] Allow egress router to run on non-default interface
Summary: [3.6] Allow egress router to run on non-default interface
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 3.6.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.6.z
Assignee: Dan Winship
QA Contact: Meng Bo
Depends On: 1513764
TreeView+ depends on / blocked
Reported: 2017-11-15 22:43 UTC by Dan Winship
Modified: 2017-12-14 21:02 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: The "assign-macvlan" pod annotation can now take the name of a network interface rather than just "true" or "false". Reason: Result: egress-routers can now be run on a non-default network interface
Clone Of: 1513764
Last Closed: 2017-12-14 21:02:32 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:3438 normal SHIPPED_LIVE OpenShift Container Platform 3.6 and 3.5 bug fix and enhancement update 2017-12-15 01:58:11 UTC

Internal Links: 1512126

Description Dan Winship 2017-11-15 22:43:11 UTC
+++ This bug was initially created as a clone of Bug #1513764 +++

Currently egress-routers always attach themselves to the network interface containing the default route. We need to make it possible to attach one to an alternate interface.

To get this out to a customer quickly, we're doing the simplest possible fix, which is to let the user manually specify a network interface (rather than, say, having OpenShift try to figure out the correct interface automatically based on EGRESS_SOURCE).

Comment 1 Dan Winship 2017-11-17 19:43:49 UTC

Comment 2 Dan Winship 2017-11-21 21:32:20 UTC
Merged... how do we get a hotfix built?

Comment 3 Dan Winship 2017-11-29 13:04:17 UTC
(In reply to Dan Winship from comment #1)
> https://github.com/openshift/ose/pull/929

(plus https://github.com/openshift/ose/pull/936 to fix the build afterward)

Comment 5 Hongan Li 2017-12-06 09:38:47 UTC
verified in atomic-openshift- and passed.

Comment 9 Ryan Howe 2017-12-07 18:57:45 UTC
Just for reference:

The annotation will still accept true and false 

    pod.network.openshift.io/assign-macvlan: "true"

this allows it to accept further values like

    pod.network.openshift.io/assign-macvlan: "eth1"

Comment 14 errata-xmlrpc 2017-12-14 21:02: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, 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.