Good point, however, the problem is only half-solved.
If the machine is coldstarted then previous devices could be randomly reshufled. Imagine you have a datacenter with 100 machines and you have some kind of provisioning scheme where you coldstart them often. It would be a nightmare having to run ethtool -p <dev> and replug cables.
We have solved the problem by providing a consistent algorithm of sorting all the devices in a udev callback. We have a known set of hardware so we know which cards are add-ons (our machines have 4+ eth ports) and which ones are built-ins. So it works out, however, it would be nice to generalize it somehow.
> If the machine is coldstarted then previous devices could be randomly reshufled.
The detection order would change, but the ifcfg file (RH) or udev rules (SuSE and others) would not change, so your NICs will stay the same these days.
ifcfg file is auto-generated by the coldstart. But you are right, if we save and restore ifcfg files then it would work. However if this saving and restoring has to be done after machine is coldstarted, its eth0 could be connected to another network completely.
That is the the problem I am trying to convey -- the machines are coldstarted often and MAC addresses are reshufled on every first boot. If your cable to the management network is connected to left socket on the motherboard, that left socket needs to be eth0 on every coldstart. Sometimes it is not. "Yes" after the first boot when ifcfg files has been written it will be stable, but that mean someone has to go and either hand-edit ifcfg files or run ethtool -p eth0 and replug the cables.
> Subsequent cold starts only read the files
No they don't. Thare no files to read. You just wrote above in your commetn that the first time OS boots ifcfg are generated. So after a machine is coldstarted there are no ifcfg files! They are generated once per coldstart and saved. Then during each restart those files are read and everything is fine.
Now, I was saying, you can have a provisioning scheme where during coldstart, in your kickstart file you can fetch and write stable ifcfg files to prevent machines from creating their own. What we do instead is install a custom RPM with a udev script where an algorithm sorts the network interfaces in a stable way (since we only deal with a known and limited set of motherboards and network cards).
> No they don't. Thare no files to read. You just wrote above in your commetn [sic] that the first time OS boots ifcfg are generate [sic]. So after a machine is coldstarted there are no ifcfg files!
As long as you don't reinstall your OS, or lose your data, your config files are there. Cold starting hardware does not delete data.
Alright, figured it out. When you talk about coldstaring you really mean restarting the machine, as in pressing the reset button for example. When I talk about coldstarting I mean starting with a bare hardware box and installing an OS on it.
> Are you trolling?
Actually I thought you were. Sorry for the misunderstanding.
[EDIT: I won't edit my previous posts, otherwise your posts won't make sense, let others laugh at my bad English (it is a 3rd language so I don't mind)]
No probs. Most places I've worked at use 'provision' or 'bare metal' for an os install plus mop up work, starting cold as a way to differentiate from warm booting, appreciate different places may have different systems though. Thanks for being classy about it :-)
If the machine is coldstarted then previous devices could be randomly reshufled. Imagine you have a datacenter with 100 machines and you have some kind of provisioning scheme where you coldstart them often. It would be a nightmare having to run ethtool -p <dev> and replug cables.
We have solved the problem by providing a consistent algorithm of sorting all the devices in a udev callback. We have a known set of hardware so we know which cards are add-ons (our machines have 4+ eth ports) and which ones are built-ins. So it works out, however, it would be nice to generalize it somehow.