Happens on bare metal environment.

This sounds like the intended behavior for os-net-config because by default we are only looking for active NICs on the system:

http://git.openstack.org/cgit/openstack/os-net-config/tree/os_net_config/utils.py#n52

This sort of assumes that any desired cabling changes are done ahead of time.

That said, we do support a strict mapping mechanism such that the NIC naming can be passed in explicitly. See this file format:

http://git.openstack.org/cgit/openstack/os-net-config/tree/etc/os-net-config/samples/mapping.yaml

Using os-net-config on the CLI we can pass this in with -m.

----

The end goal is for the mapping file to be generated by something like an Ironic plugin (edeploy discovery plugin)... and then we should know for sure which nic is mapped to nic1, nic2, ....

Leonid, can you look at this one again after reviewing comment #2

Chris,
How exactly do I need to check this issue ? I understand that os-net-config  is meant to only configure the active NICs on the system. I have tried to check the -m switch but couldn't find yaml file in the /etc/os-net-config directory.

Dan, can you provide guidance or a link to docs that describe how the mapping.yaml file should be used/created?

I'm not sure we document the usage for this feature in tripleo-docs. But we do have a sample mapping file in the os-net-config source code:

http://git.openstack.org/cgit/openstack/os-net-config/tree/etc/os-net-config/samples/mapping.yaml

Moving to documentation team to cover this usage. Dan, would you be able to help docs team if they have questions?

Hello

I thinks is not a documentation part, is related to this commit https://review.openstack.org/#/c/265014

Could be better to use that regarding upgrade processing.

Regards

Seems like a better fit for Networking DFG.

As far as I know os-net-config is HardProv's baby.

(In reply to Jaromir Coufal from comment #8)
> Moving to documentation team to cover this usage. Dan, would you be able to
> help docs team if they have questions?

Sure, I'm up for helping with the documentation on this issue.

Dan

Bob, mind taking a look (feel free to assign further).

Moving to Documentation. The doc text has already been written. I can help with any questions or changes to this text.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1437320, in which a fix is proposed to map the nics with no-carrier if they are defined in a mapping file.

Moving to 'NEW' to be triaged as resources allow.

Looks like the best place for this is under `Isolating Networks` - 7.1. Creating Custom Interface Templates:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html-single/advanced_overcloud_customization/#sect-Creating_Custom_Interface_Templates


This section includes coverage of os-net-config.

I agree with Dan, the section under Configuring Interfaces in this doc explains that only interfaces which are UP will be used so putting it in the Creating Custom Interface Templates section is not necessary.

The description may need to be expanded to describe that a custom mapping file can be provided.  In that case the actual interface names will be mapped to the names in the mapping file regardless of the state of the link, i.e. even down links will be mapped.

(In reply to Bob Fournier from comment #23)
> The description may need to be expanded to describe that a custom mapping
> file can be provided.  In that case the actual interface names will be
> mapped to the names in the mapping file regardless of the state of the link,
> i.e. even down links will be mapped.

Hi Bob,

Is the mapping necessary? My understanding is that you can use the interface name ("eth0", "eth1", "enp0s25") instead of the standard "nic1", "nic2", etc, and that  the "nicX" convention is mainly used to standardize interfaces across nodes using different hardware (e.g. you have two compute nodes -- one using "ethX" and the other using "emX").

Dan,

Yes exactly, the mapping convention done by os-net-config is used so that the actual interface names need not be known and can be different across nodes.  The mapping file is not necessary - os-net-config checks first to see if one exists and will use it if it does, otherwise it will do the standard, ordered mapping as you described.  The mapping file can help in situations, for example, in which you have more live interfaces on one node and you want to ensure that the mapping is done consistently.

Okay, I understand now. Is there a syntax for the mapping file? Would this just be a standard environment file that you include upon deployment?

Sorry for all these questions. :S

Dan,

The syntax is just standard yaml file with mappings under "interface_mapping", for example:

cat mapping.yaml 
interface_mapping:
  nic1: em2 
  nic2: em1 
  nic3: a0:36:9f:bc:22:82
  nic4: a0:36:9f:bc:22:80
  nic5: 90:1b:0e:9a:cb:1c
  nic6: 90:1b:0e:9a:cb:1d

By default, os-net-config looks for the file at /etc/os-net-config/mapping.yaml
but this location can be overridden if you run os-net-config manually by the -m option.

You would have to generate the file, for example by a first boot script:https://github.com/openstack/tripleo-heat-templates/blob/master/firstboot/os-net-config-mappings.yaml

Note also, in example above, that the mapping file can be used in situations where you want to map the NICs mac address to a specific alias.

Ah, thanks Bob!

Martin, we should document how to implement these mappings in that appendix. I'll catch up with you in the office tomorrow in case you need a hand with documenting this.

Bob has approved draft via email.

Hi Dan - can this be closed?

Hi Bob,

I think this got lost in my bug filter. I'm currently revamping the networking section in that guide (there's a lot of out-of-date info) and will factor in this content. I'll get this resolved before the end of the week.

- Dan

Merged with original osp12 branch. For the osp13 and master, I added the content to an existing module on network interface mapping.

Closing as per comment 37.