On Tue, 2010-11-16 at 09:24 -0500, Matthew Miller wrote: > On Sun, Nov 14, 2010 at 07:53:40AM -0600, Matt Domsch wrote: > > > > biosdevname installed by default, used in the installer and at runtime > > > > to rename Dell and HP server onboard NICs from non-deterministic > > > > "ethX" to clearly labeled "lomX" matching the chassis silkscreen. > > > But why ???lomX??? for all? Isn't Lights-Out-Management available only on first > > > ethernet port and often on dedicated port? > > This has nothing to do with Lights-Out-Management. LOM also == LAN on > > Motherboard. > > Since you're already silkscreening this on the chassis of your systems, > clearly this ship is well out of the harbor, but that confusion seems like a > completely legitimate concern. Seems like it could easily result in > management interfaces getting plugged into the wrong networks. > > Also, I gotta say, it really shouldn't be LAN on Motherboard, since it's > just an adapter, not actually a whole lan. It should clearly be NIC on > Motherboard, or "nom". And then you could silkscreen lolcats on to the > servers, which I think would be a win for everyone. I've had a few off-list conversations with various community members about this. One thing that came up was that the alternative namespace is necessary, but also that "lom" is a sub-optimal choice. One idea that did come up was simply to call them "net" (net0, etc.) or perhaps "net" followed by another letter like "netm" or something. To avoid bikeshedding this to death though, I think Matt's "lom" naming is fine for the moment unless we happen to all agree on something else. Meanwhile, there are two other things I'm keeping ticking over: 1). Potential kernel-based solutions to augment this (but not otherwise affect what would be in F-15). More on that another time. 2). Naming of non-network devices. Both DMTF and other groups (ACPI, PCI, etc.) looking at the problem of persistent device to slot mappings have all looked at more than network. While Matt is (rightfully) looking at networking in F-15, we need to remember this problem actually will in future also necessitate work on other non-network devices, too. Jon. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
