In the Network JSON, there is a mapping based on PCI bus order for the NIC's per platform. If you add your platform's PCI bus mapping there, you will control the nic enumeration behavior. This allows the PCI bus enumeration to control the nic naming order and not the OS enumeration. The design was put in place to support multiple OS's as each OS enumerates and names NIC's differently sometimes changes the names on the fly it was decided to stick to PCI bus ordering.
If the Platform does not have a mapping, then the fall back is PCI bus order as sorted from lowest to highest. ----------------- Randy Perryman Dell | Cloud and Big Data Solutions [email protected] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -----Original Message----- From: crowbar-bounces On Behalf Of Ralf Haferkamp Sent: Wednesday, August 07, 2013 8:19 AM To: crowbar Subject: [Crowbar] Crowbar's internal NIC enumeration Hi, While analyzing a bug report, I just stumbled over a weirdness in how the network barclamp (pebbles) enumerates network interfaces of different speeds internally. Assuming you have a node with two 1GBit and one 10Gbit interface. No custom ordering is defined in the interface map and the NICs are detected as: eth0 -> first 1GBit, eth1 -> 10Gbit and eth2-> second 1GBit. Internally (in Barclamp::Inventory.build_node_map in barclamp_lib.rb) crowbar will map these interfaces to the following internal names: eth0: 1g1, 100m1, 10m2 eth1: 10g1, 1g2, 100m2, 10m2 eth2: 1g3, 100m3, 10m3 That means: 1. every NIC will get several (internal) names, one for each speed it supports 2. the counter in the interface name is per supported speed. I.e. internally in crowbar eth1 is regarded as the first 10Gig NIC and the 2nd 1Gig NIC. This might sound logically in the first place but can have interesting effects for conduit_maps. E.g. if I want do use the second 1 GBit NIC for the the intf1 conduit I would have to specify "1g3" in the conduit map is that really the desired behavior? Or is this a bug? Is this documented somewhere? -- Ralf _______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/ _______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
