[openstack-dev] Blueprint to change (expand) traditional Ethernet interface naming schema in Fuel
asyriy at mirantis.com
Mon Oct 19 09:36:20 UTC 2015
Continue work on the Ethernet interfaces naming schema I create the
blueprint and spec for review:
Because proposed changes potentially affect different components (and
actually it's out of my expertise) I would like to ask core reviewers to
assess the risks and write comment in corresponding sections (marked as
Looking forward to your reply,
On Fri, Oct 9, 2015 at 10:30 PM, Sergey Vasilenko <svasilenko at mirantis.com>
> > I would like to pay your attention to the changing interface naming
>> > schema, which is proposed to be implemented in FuelA .A In brief,
>> > Ethernet network interfaces may not be named as ethX, and there is a
>> > reported bug about itA 
>> > There are a lot of reasons to switch to the new naming schema, not
>> > because it has been used in CentOS 7 (and probably will be used in
>> > Ubuntu LTS), but becauseA new naming schema gave more predictable
>> > interface namesA . There is a reported bug related to the topicA
> 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).
> 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
> I can support config format from os-net-config as additional network
> scheme format too, but, IMHO, this hierarchical format not so convenient as
> NIC mapping, in Nailgun, already implemented in the template-networking.
> If wee need use it for another cases -- ask Alexey Kasatkin, please.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev