Open Stack

>
> >    I would like to pay your attention to the changing interface naming
> >    schema, which is proposed to be implemented in FuelA [1].A In brief,
> >    Ethernet network interfaces may not be named as ethX, and there is a
> >    reported bug about itA [2]
> >    There are a lot of reasons to switch to the new naming schema, not
> only
> >    because it has been used in CentOS 7 (and probably will be used in
> next
> >    Ubuntu LTS), but becauseA new naming schema gave more predictable
> >    interface namesA [3]. There is a reported bug related to the topicA
> [4]
>

L23network module is a interface naming scheme agnostic.
Only bridge and bond interface name protection found -- You can't call bond
or bridge like 'enp2s0', because this name reserved for NICs.



> You might be interested to look at the os-net-config tool - we faced this
> exact same issue with TripleO, and solved it via os-net-config, which
> provides abstractions for network configuration, including mapping device
> aliases (e.g "nic1") to real NIC names (e.g "em1" or whatever).
>
> https://github.com/openstack/os-net-config
>
>
It's interesting project. Proposed format for network configuration, so
interesting, but...
Project too young. And doesn't allow to configure some things, that
L23network already support.
Main problem of this project -- is a approach to change interface options
options. They doesn't use prefetch/flush mechanics as in the puppet. They
just executing commands for change, instead in most cases. Such approach
doesn't allow re-configure existing cloud properly, if one under production
load.

I can support config format from os-net-config as additional network scheme
format too, but, IMHO, this hierarchical format not so convenient as flat.

NIC mapping, in Nailgun, already implemented in the template-networking. If
wee need use it for another cases -- ask Alexey Kasatkin, please.

/sv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151009/52adf272/attachment.html>