<div dir="ltr">Hi folks, <div><br></div><div>There was interesting research today on random nics ordering for nodes in </div><div>bootstrap stage. And in my opinion it requires separate thread...</div><div>I will try to describe what the problem is and several ways to solve it.</div><div>Maybe i am missing the simple way, if you see it - please participate.</div><div>Link to LP bug: <a href="https://bugs.launchpad.net/fuel/+bug/1394466">https://bugs.launchpad.net/fuel/+bug/1394466</a></div><div><br></div><div>When a node is booted first time it registers its interfaces in nailgun, see sample of data (only related to discussion parts):</div><div>- name: eth0</div><div>  ip: <a href="http://10.0.0.3/24">10.0.0.3/24</a></div><div>  mac: 00:00:03</div><div>- name: eth1</div><div>  ip: None</div><div>  mac: 00:00:04</div><div>* eth0 is admin network interface which was used for initial pxe boot</div><div><br></div><div>We have networks, for simplicity lets assume there is 2:</div><div> - admin</div><div> - public</div><div>When the node is added to cluster, in general you will see next schema:</div><div><div>- name: eth0</div><div>  ip: <a href="http://10.0.0.3/24">10.0.0.3/24</a></div><div>  mac: 00:00:03</div><div>  networks:</div><div>    - admin</div><div>    - public</div><div>- name: eth1</div><div>  ip: None</div><div>  mac: 00:00:04</div></div><div><br></div><div>At this stage node is still using default system with bootstrap profile, so there is no custom system with udev rules. And on next reboot there is no way to guarantee that network cards will be discovered by kernel in same order. If network cards is discovered in order that is diffrent from original and nics configuration is updated, it is possible to end up with:</div><div><div>- name: eth0</div><div>  ip: None</div><div>  mac: 00:00:04</div><div>  networks:</div><div>    - admin</div><div>    - public</div><div>- name: eth1</div><div>  mac: 00:00:03</div></div><div>  ip: <a href="http://10.0.0.3/24">10.0.0.3/24</a><br></div><div>Here you can see that networks is left connected to eth0 (in db). And ofcourse this schema doesnt reflect physical infrastructure. I hope it is clear now what is the problem.</div><div>If you want to investigate it yourself, please find db dump in snapshot attached to the bug, you will be able to find described here case.</div><div>What happens next:</div><div>1. netcfg/choose_interface for kernel is misconfigured, and in my example it will be 00:00:04, but should be 00:00:03</div><div>2. network configuration for l23network will be simply corrupted</div><div><br></div><div>So - possible solutions:</div><div>1. Reflect node interfaces ordering, with networks reassignment - Hard and hackish</div><div>2. Do not update any interfaces info if networks assigned to them, then udev rules will be applied and nics will be reordered into original state - i would say easy and reliable solution</div><div>3. Create cobbler system when node is booted first time, and add udev rules - it looks to me like proper solution, but requires design</div><div><br></div><div>Please share your thoughts/ideas, afaik this issue is not rare on scale deployments.</div><div>Thank you</div></div>