Open Stack

Hello,

Continue work on the Ethernet interfaces naming schema I create the
blueprint and spec for review:
https://blueprints.launchpad.net/fuel/+spec/network-interfaces-naming-schema
https://review.openstack.org/#/c/236848/

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
TODO).

Looking forward to your reply,

Albert Syriy,

Software Engineer,
Mirantis

On Fri, Oct 9, 2015 at 10:30 PM, Sergey Vasilenko <svasilenko at mirantis.com>
wrote:

> >    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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151019/8206c46a/attachment-0001.html>