Bug 1457465

Summary: os-net-config does not pick up an existing mapping file
Product: Red Hat OpenStack Reporter: ben haubeck <bhaubeck>
Component: os-net-configAssignee: Bob Fournier <bfournie>
Status: CLOSED ERRATA QA Contact: Dan Yasny <dyasny>
Severity: high Docs Contact:
Priority: high    
Version: 11.0 (Ocata)CC: aschultz, bfournie, dyasny, hbrock, ipetrova, jjoyce, jslagle, mburns, mlammon, pcaruana, rhel-osp-director-maint, yjog
Target Milestone: z1Keywords: Triaged, ZStream
Target Release: 11.0 (Ocata)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: os-net-config-6.1.0-1.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1477316 (view as bug list) Environment:
Last Closed: 2017-07-19 17:04:56 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: 1477316    
Attachments:
Description Flags
md5 checksum of sosreport
none
mapping.yaml none

Comment 2 ben haubeck 2017-05-31 19:12:20 UTC
Created attachment 1283880 [details]
md5 checksum of sosreport

Comment 4 ben haubeck 2017-05-31 19:29:56 UTC
Created attachment 1283885 [details]
mapping.yaml

Comment 5 ben haubeck 2017-05-31 19:52:01 UTC
Created attachment 1283894 [details]
config.json

Comment 6 Alex Schultz 2017-05-31 22:47:36 UTC
So the issue that if you have an ovsbond, the mappings are not applied to the members of the ovsbond. This is also true for any such constructs. Mappings only work on top level network interfaces in os-net-config. A workaround is to include a nic_mapping on the first interface in the group which will result in the mappings being loaded.

Comment 8 Alex Schultz 2017-05-31 22:52:44 UTC
It should be noted that the nic_mapping has to be on the *first loaded* interface. So load order matters. To be safe you could just include it on every member.  Ideally this should be fixed in os-net-config to consume the global mapping file.

Comment 9 ben haubeck 2017-06-01 11:44:58 UTC
the fix, to put the nic mapping in config.json is not helping for the general deployment issue (that is failing as the nic mapping is not being used) as the config.json - in contrast to the mapping.yaml - is getting rewritten before the deployment starts. 
so the nic mapping is gone before it is needed.

Comment 11 Bob Fournier 2017-06-02 01:34:12 UTC
Upstream fix in progress - https://review.openstack.org/#/c/470073/

Comment 13 Bob Fournier 2017-06-20 10:07:27 UTC
>Hey Bob, 

>The upstream fix has been merged +10 days ago as far as I can tell. Any progress on >this downstream? 

Backport to ocata is in progress - https://review.openstack.org/#/c/475531/.  Will update bug when patch is merged.

Comment 14 Bob Fournier 2017-06-26 13:51:17 UTC
https://review.openstack.org/#/c/475531/ backport to Ocata has merged.

Comment 16 Bob Fournier 2017-06-29 12:58:48 UTC
Pablo,

I believe that teaming was added in OSP-10, I'm not sure when the ability for a user to provide a mapping file was added.  This bug can affect all releases that have nested objects i.e. bridges, bonds, teams etc. in which a custom mapping file is provided.  It does not affect network config when a custom mapping file is not provided.

Comment 18 Dan Yasny 2017-07-18 20:05:35 UTC
verified in os-net-config-6.1.0-1.el7ost.noarch

Comment 20 errata-xmlrpc 2017-07-19 17:04:56 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.

https://access.redhat.com/errata/RHBA-2017:1778