On Fri, Aug 26, 2016 at 08:40:49AM -0700, Luke Bigum wrote:
> 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
What a name!
> 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
Maybe OS too old? The interface name "p4p2" also looks fishy.
> > 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.
Yes. I have never seen an installation doing it _this_ right in the
first iteration.
> > > > 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".
Yes, but dropping a supplementary file does not mean that a role has
parameters. And also, it would be duplication if one had two distinct
roles that would only differ in single setting?
> 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
That's the way it's in the books. What I'd like to see clarified (and
explained why) is that this tree should have "and nothing else" spelled
out in multiple places:
Node (has one) ->
Role (and nothing else!)
Role (has one or more) ->
Profile (and nothing else!)
Profile (has one or more) ->
Defined Type (has zero or more) ->
Resources
or Class (has zero or more) ->
Resources
or Resource
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/20160827175059.GB2471%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
