Marc, We use VMware's vSphere, which still results in "random" but predictable interface names - eth0 is now eno16780032, eth1 is now eno3359296, etc. We've stuck with that because while it's somewhat painful (eth# is soooooo much easier to comprehend), it's far less painful to memorize that than to maintain some udev rules that may need tweaked across time. However, if we were on bare metal, it might be worth disabling the rules to get the older style back. That's probably still less optimal than customized names, but it's well documented at least. For example, http://carminebufano.com/?p=108 or http://amolkg.blogspot.in/2015/05/centos-7-change-network-interface-name.html - though there are multiple ways to do it even then.
Rob Nelson rnels...@gmail.com On Wed, Aug 24, 2016 at 9:55 AM, Marc Haber <mh+puppet-us...@zugschlus.de> wrote: > Hi, > > I would like to discuss how to handle systemd's new feature of > predictable network interface names. This is a rather hot topic in the > team I'm currently working in, and I'd like to solicit your opinions > about that. > > On systems with more than one interface, the canonical way to handle > this issue in the past was "assume that eth0 is connected to network > foo, eth1 is connected to network bar, and eth2 is connected to > network baz" and to accept that things fail horribly if the order in > which network interfaces are detected changes. > > While upstream's focus is as usual on desktop machines where Ethernet, > USB and WWAN interfaces come and go multiple times a day (see > upstream's reasoning in > https://www.freedesktop.org/wiki/Software/systemd/ > PredictableNetworkInterfaceNames/), > this seldomly happens in our happy server environment, which reduces > the breakage potential to disruptive kernel updates or vendor firmware > changes peddling with the order in which network interfaces are > enumerated. > > This happens rather seldomly in my experience. > > I would, however, like to stay with the new scheme since I see its > charms. > > But, how would I handle this in a puppetized environment? > > Currently, the code that is already, for example for a firewall > assumes that eth0 is the external interface, eth1 the internal one and > eth2 the perimeter networks. > > In the new setup, all those interfaces can have different names > depending on different hardware being used. That means that the same > puppet code cannot be used on one firewall instance running on Dell > hardware and a second one running on HP hardware because BIOS indices > and/or PCI paths will vary. If I used the MAC scheme, things are even > worse since interface names will be different even on different pieces > of otherwise identical hardware. > > Many of my team members thinkt hat one should simply turn of > predictable network interface names altgether and so that our old code > continues to work. I think that this would be a bad idea, but don't > have any logical arguments other than my gut feeling. > > Generating udev rules to fix the network names (and assign names like > ext1, int1, per1) already in postinst of the OS does not work since we > don't know how the machine is going to be wired and even used. > > Any ideas? How do _you_ do this? > > Greetings > Marc > > -- > ------------------------------------------------------------ > ----------------- > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 > Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/puppet-users/20160824135527.GP2471%40torres.zugschlus.de. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAC76iT8YZCWeKDB%2BdPiTRxE80WTe2BrCL%3D1hJEFteZKJF-gHEw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
