On Friday, 26 August 2016 10:57:25 UTC+1, Marc Haber wrote:
>
> On Thu, Aug 25, 2016 at 08:08:13AM -0700, Luke Bigum wrote:
> > On Thursday, 25 August 2016 13:21:24 UTC+1, Marc Haber wrote:
> > > On Wed, Aug 24, 2016 at 08:36:49AM -0700, Luke Bigum wrote:
> > > > Here we have very strict control over our hardware and what
> interface
> > > goes
> > > > where. We keep CentOS 6's naming scheme on Dell hardware, so p2p1 is
> PCI
> > > > slot 2, Port 1, and don't try rename it.
> > >
> > > Isn't CentOS 6 still using eth0, 1, 2, 3? How do you handle different
> > > hardware having different slot numbers, or PCI bridges shifting bus
> > > numbers?
> > >
> >
> > I find this depends on the manufacturer. I've never come across a Dell
> > server newer than an R510 that *doesn't* give you PCI based names. I
> just
> > checked an R510 and it does. All of our ancient HP gear (7 years, older
> > than the R510s which is old) give the ethX names. Also random SuperMicro
> > hardware gives ethX. I don't really know what's missing for the kernel /
> > udev to name them so, but for us it doesn't really matter.
>
> Can you run
> $ for iface in /sys/class/net/*; do echo $iface; sudo udevadm info -q all
> -p $iface | grep ID_NET_NAME; done
> on some of your gear? I'd like to learn what different vendors deliver.
>
>
My Dell XPS 13, 2016 model:
/sys/class/net/docker0
/sys/class/net/enp0s20u1u3i5
E: ID_NET_NAME_MAC=enx9cebe824ebee
E: ID_NET_NAME_PATH=enp0s20u1u3i5
/sys/class/net/lo
/sys/class/net/virbr0
/sys/class/net/virbr0-nic
/sys/class/net/virbr1
/sys/class/net/virbr1-nic
/sys/class/net/virbr2
/sys/class/net/virbr2-nic
/sys/class/net/wlp2s0
E: ID_NET_NAME=wlp2s0
E: ID_NET_NAME_MAC=wlxacd1b8c05607
E: ID_NET_NAME_PATH=wlp2s0
For both the Dell R720 and R730, there's no NET_NAME stuff:
[root@r720 ~]# udevadm info -q all -p /sys/class/net/p4p2
P: /devices/pci0000:40/0000:40:02.0/0000:42:00.1/net/p4p2
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:40/0000:40:02.0/0000:42:00.1/net/p4p2
E: INTERFACE=p4p2
E: IFINDEX=7
E: SUBSYSTEM=net
And this is an FC430, which is a blade-like chassis with internal PCI
switches:
[root@FC430 ~]# udevadm info -q all -p /sys/class/net/p5p1/
P:
/devices/pci0000:00/0000:00:03.0/0000:02:00.0/0000:03:01.0/0000:04:00.0/0000:05:0c.0/0000:08:00.0/net/p5p1
E: UDEV_LOG=3
E:
DEVPATH=/devices/pci0000:00/0000:00:03.0/0000:02:00.0/0000:03:01.0/0000:04:00.0/0000:05:0c.0/0000:08:00.0/net/p5p1
E: INTERFACE=p5p1
E: IFINDEX=6
E: SUBSYSTEM=net
> What I get from the abstraction above is being able to take our
> > profiles and re-use them in a completely different site on the other
> > side of the world, or in a staging / testing environment. So I don't
> > have the concept of "VLAN 123 in Production UK", I've just got "The
> > STORAGE network" which in Production UK happens to be vlan 123
> > (buried low down in Hiera, and only specified once once), but in Dev
> > it's 456, and over there it doesn't exist so we'll give it the same
> > vlan tag as the CLIENT network, etc... The physical-ness of the
> > network is abstracted from the concepts our software relies on.
>
> Yes, that is a really nice concept with should have been considered
> here years ago. Alas, people didn't.
>
To be fair we didn't design it this way from the start, it's only in the
last couple evolutions that abstraction appeared. What we did have from the
start though was the concept that the same network segment in different
environments would have the same IP address segments, so the DATABASE
network over here is 1.15.7.0, and over there it's 1.40.7.0. The third
octet for the same network segment at different sites is the same (and
hopefully the same VLAN tag on switches, but not mandatory). It's easy to
abstract the numbers into names from there. However there's no reason why
we couldn't use the same abstraction idea for vastly different or public IP
ranges, it would just require more Hiera glue.
> > > So you do create network interfaces in the profile and not in the
> > > role?
> > >
> >
> > We try to follow the design rule that "Roles only include Profiles".
>
> ... "and don't define their own resources", you mean?
>
> That's one of the aspects of the role-and-profiles approach that I
> have never seen spelled out explicitly, but still honored by nearly
> anybody, and I have not yet fully grokked the reasons for doing so.
>
Yes, we definitely don't define resources, and don't include component /
base level classes. I think we pulled it from an early Gary Larizza post,
along with "roles don't have parameters, if you need to configure a role
you've got two different roles". All rules subject to be broken if someone
is in a hurry/lazy (which is too often).
I've always understood the logic to be based on the layers of abstraction
the role/profile design is trying to achieve. I always envision this tree:
Node (has one) ->
Role (has one or more) ->
Profile (has one or more) ->
Defined Type (has zero or more) ->
Resources
or Class (has zero or more) ->
Resources
or Resource
--
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/06d23d4d-8801-4b2b-a387-948747d616ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
