<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><div class="gmail_quote">>    I would like to pay your attention to the changing interface naming<br>
>    schema, which is proposed to be implemented in FuelA [1].A In brief,<br>
>    Ethernet network interfaces may not be named as ethX, and there is a<br>
>    reported bug about itA [2]<br>
>    There are a lot of reasons to switch to the new naming schema, not only<br>
>    because it has been used in CentOS 7 (and probably will be used in next<br>
>    Ubuntu LTS), but becauseA new naming schema gave more predictable<br>
>    interface namesA [3]. There is a reported bug related to the topicA [4]</div></div></div></blockquote><div><br></div><div>L23network module is a interface naming scheme agnostic. </div><div><font face="arial, helvetica, sans-serif">Only bridge and bond interface name protection found -- You can't call bond or bridge like '<span style="color:rgb(46,26,5);font-size:13.13px">enp2s0', because this name reserved for NICs.</span></font></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><div class="gmail_quote">
You might be interested to look at the os-net-config tool - we faced this<br>
exact same issue with TripleO, and solved it via os-net-config, which<br>
provides abstractions for network configuration, including mapping device<br>
aliases (e.g "nic1") to real NIC names (e.g "em1" or whatever).<br>
<br>
<a href="https://github.com/openstack/os-net-config" rel="noreferrer" target="_blank">https://github.com/openstack/os-net-config</a><br>
</div><div class="gmail_quote"><br></div></div></div></blockquote><div><br></div><div>It's interesting project. Proposed format for network configuration, so interesting, but...</div><div>Project too young. And doesn't allow to configure some things, that L23network already support.</div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>NIC mapping, in Nailgun, already implemented in the template-networking. If wee need use it for another cases -- ask Alexey Kasatkin, please.</div><div><br></div></div>/sv</div></div>