Bug 1513764

Summary: Allow egress router to run on non-default interface
Product: OpenShift Container Platform Reporter: Dan Winship <danw>
Component: NetworkingAssignee: Casey Callendrello <cdc>
Networking sub component: openshift-sdn QA Contact: zhaozhanqi <zzhao>
Status: CLOSED EOL Docs Contact:
Severity: medium    
Priority: medium CC: aos-bugs, bbennett, erich, hongli, mcurry, rhowe, smunilla, xtian
Version: 3.8.0   
Target Milestone: ---   
Target Release: 3.8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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
 Story Points: ---
Clone Of:
: 1513767 1513768 (view as bug list) Environment:
Last Closed: 2019-12-05 21:59:22 UTC Type: Bug
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:    
Bug Blocks: 1513767, 1513768    

Description Dan Winship 2017-11-15 22:40:45 UTC 
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-27 12:43:21 UTC 
https://github.com/openshift/origin/pull/17334
Comment 2 Ryan Howe 2017-12-07 18:56:22 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 8 Meng Bo 2018-03-07 10:44:38 UTC 
The bug has been fixed on v3.9.3