Re: [Puppet Users] How to use class in different place

[Henrik Lindberg]

On 25/08/16 22:40, Albert Shih wrote:

Hi,

I would like to known how can I use a class in different place. Let's take
a example.

I have a module who manage a CMS, let's say something like drupal (or
whatever you want). So in this CMS I need to use apache class. So I get in
my

  node.yaml

something like

  classes :
- my_drupal_class

  my_drupal_class::options::config1:
  my_drupal_class::options::config2:
  ...
  my_drupal_class::options::confign:


So now lets say I need a very simple vhost on that host. How can I do that
? If I load the class { apache } puppet going to complain because it's
already loaded inside my_drupal_class. If I don't load the class { apache }
I'm going to loose most of the params.pp (Like the version, the logpath
etc..)

Regards.



The recommended approach is to always use 'include()' to include the 
classes (you can include the same class any number of times). You then 
use data binding (that is, automatic binding of class parameters to 
values) by storing the parameters in hiera.


This way, all use of a class will get exactly the same parameter values
and the things being managed are only managed once. (As you noted you 
cannot manage the same thing more than once using the resource like way 
of creating a class where you can give it its parameter values even if 
you were to give it exactly the same values).


Hope that helps.

- henrik


JAS



--
Albert SHIH
DIO bātiment 15
Observatoire de Paris
5 Place Jules Janssen
92195 Meudon Cedex
France
Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
xmpp: j...@obspm.fr
Heure local/Local time:
jeu 25 aoū 2016 22:35:41 CEST




--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
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/9bc8c891-c9ee-722a-80f7-a97ce2adc677%40puppet.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] How to use class in different place

[Albert Shih]

Hi,

I would like to known how can I use a class in different place. Let's take
a example.

I have a module who manage a CMS, let's say something like drupal (or
whatever you want). So in this CMS I need to use apache class. So I get in
my

  node.yaml

something like

  classes :
- my_drupal_class

  my_drupal_class::options::config1:
  my_drupal_class::options::config2:
  ...
  my_drupal_class::options::confign:


So now lets say I need a very simple vhost on that host. How can I do that
? If I load the class { apache } puppet going to complain because it's
already loaded inside my_drupal_class. If I don't load the class { apache }
I'm going to loose most of the params.pp (Like the version, the logpath
etc..)

Regards.

JAS



--
Albert SHIH
DIO bātiment 15
Observatoire de Paris
5 Place Jules Janssen
92195 Meudon Cedex
France
Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
xmpp: j...@obspm.fr
Heure local/Local time:
jeu 25 aoū 2016 22:35:41 CEST

-- 
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/20160825204011.aejr6h677x3s2xzp%40pcjas.obspm.fr.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppet ignores storeconfig_backend in puppet.conf

[Joseph Lorenzini]

Hi all,

I am encountered an odd behavior when i revoke a certificate on the puppet 
master. I see this error. I am using puppet 3.7.4 on CentOS 7.

Error: undefined method `verify_active_connections!' for 
ActiveRecord::Base:Class


This leads me to think that when a revocation is happening, the 
storeconfig_backend is set to activerecord. However, i have specifically 
configured /etc/puppet/puppet.conf to use puppetdb. Here's the master 
section in /etc/puppet.conf

[master]
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

storeconfigs = true
storeconfigs_backend = puppetdb
  #  reports = puppetdb,tagmail
reports = puppetdb
pluginsync=true


Does anyone know what might  be going on here?

Thanks,
Joe 

-- 
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/d9c3e498-fe6c-4d47-8c84-56dfd2c4bf17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Announce: PuppetDB 4.2.2 is released!

[Wyatt Alt]

PuppetDB 4.2.2 - August 25, 2016

PuppetDB 4.2.2 Downloads



Available in native package format as part of Puppet Collection 1 (PC1).
More information on the PC1 repositories is available here:
http://bit.ly/1HQJDNb

Binary tarball: http://downloads.puppetlabs.com/puppetdb/

Source: http://github.com/puppetlabs/puppetdb

Please report feedback via the Puppet Labs tickets site by submitting a
ticket with an "Affects Version" field of "PDB 4.2.2":
https://tickets.puppetlabs.com/browse/PDB

Documentation: http://docs.puppetlabs.com/puppetdb/4.2/

Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb

PuppetDB 4.2.2 Release Notes



PuppetDB 4.2.2 is a backward-compatible bugfix release that fixes an issue
with a migration up to 4.2.0 that could cause an out of memory error and
reduces CPU usage associated with our internationalization library.


Consult the release notes for more information: https://docs.puppetlabs.com/
puppetdb/4.2/release_notes.html.


-- 
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/CAJDiH3GFsZ_i85EKXA1oMZQGKERV7QG04gT5VtsafVLXSe%3DBrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to handle predictable network interface names

[Luke Bigum]

On Thursday, 25 August 2016 13:31:17 UTC+1, Marc Haber wrote:
>
> On Wed, Aug 24, 2016 at 09:03:16AM -0700, Luke Bigum wrote: 
> > The template will create udev rules from two sources. The first is 
> > @interfaces, which is the giant multi-level hash of network interfaces 
> that 
> > our old designs use. A VM might look like this in Hiera: 
> > 
> > networking::interfaces: 
> >   eth0: 
> > ipaddr: 1.1.1.1 
> > hwaddr: 52:54:00:11:22:33 
> > 
> > The second source of udev rules is also a Hash and also from Hiera, but 
> > rather than it be embedded in the giant hash of networking information, 
> it 
> > is there to compliment the newer role/profile approach where we don't 
> > specify MAC addresses. This is purely a cosmetic thing for VMs to make 
> our 
> > interface names look sensible. Here is a sanitised Hiera file for a VM 
> with 
> > the fictitious "database" profile: 
> > 
> > profile::database::subnet_INTERNAL_slaves: 
> >   - 'eth100' 
> > profile::database::subnet_CLIENT_slaves: 
> >   - 'eth214' 
> > networking::extra_udev_static_interface_names: 
> >   eth100: '52:54:00:11:22:33' 
> >   eth214: '52:54:00:44:55:66' 
>
> So the "database" machine wouldn't have an entry in 
> networking::interfaces at all, or could one define, for example, the 
> management interface in networking::interfaces and the database 
> interfaces in the machine-specific hiera tree? 
>

That's technically possible with our module, yes, although I personally 
don't want to mix the styles. It has to do with our Hiera hierarchy being 
mostly based on physical location and entire "instances" of our 
application, where what we're talking about here is functionality based. If 
we had a business rule where "every server in this data centre has 
management interface eth76" then yeah, that would match our Hiera hierarchy 
perfectly. We don't have those hard and fast rules though, we've got 
several management networks, with different levels of security applied, 
appropriate for different layers of our application. So our management 
networks are a function of defence in depth security design alongside our 
software, rather than a simple physical location or group of VMs. Since 
they're a function of design or "business logic", rather than location, our 
management networks are defined in profiles (on new systems) because it's 
only at the role/profile level do you know that a "database" server should 
have a certain type of management network.

In my current profiles though I started with the management interfaces 
inside the same software profiles. Turns out this was not the best idea as 
they are not directly related, and what our roles should really look like 
is this:

***
class role::database {
  include profile::mandatory#Everything mandatory 
on EL6
  include profile::authentication   #Authentication is not 
mandatory
  include profile::database  #The profile that does 
most of the work for our software
  class { 'profile::management':   #management network 
definition and dependent services (sshd, etc)
 type => 'database'   #but for a specific 
type of machine
  }
}
***

So management would be separate. This would allow me to do smarter ordering 
of Puppet classes for management services like SSH (and remove a little bit 
more Hiera glue).


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/651d7a2d-8eac-49d6-aaac-8e03937dc7c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to handle predictable network interface names

[Luke Bigum]

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.

>  We have a 3rd party patch manager tool (patchmanager.com), LLDP on 
> >  our switches, and a Nagios check that tells me if an interface is not 
> >  plugged into the switch port it is supposed to be plugged into 
> >  (according to patchmanager). 
>
> Nice ;-) Is the code for the Nagios stuff public? 
>

Unfortunately no :-( Another one of those LMAX modules that's had years of 
development but too much company specific stuff hard coded in it to 
release. It's not a huge amount though, and I did just ask my Lead if I 
could clean up our networking module and release it and he was more than 
happy, I'm sure I could do the same for our nagios module. Watch this 
space, but don't hold your breath.


>  This works perfectly on Dell hardware because the PCI name mapping 
> >  works. 
>
> And you don't have many different kinds of servers. 


We try keep as few as possible, but it's not that small a list:

***
[root@puppet ~]# mco facts productname
Report for fact: productname

.found 1 times
KVM  found 603 times
OptiPlex 7010found 1 times
OptiPlex 7020found 2 times
PowerEdge FC430  found 15 times
PowerEdge FC630  found 56 times
PowerEdge R220   found 1 times
PowerEdge R320   found 92 times
PowerEdge R330   found 1 times
PowerEdge R510   found 17 times
PowerEdge R520   found 66 times
PowerEdge R720   found 36 times
PowerEdge R720xd found 30 times
PowerEdge R730   found 7 times
PowerEdge R730xd found 37 times
Precision Tower 5810 found 10 times
Precision WorkStation T5500  found 7 times
ProLiant DL360 G6found 2 times
ProLiant DL380 G5found 16 times
ProLiant DL380 G6found 11 times
To Be Filled By O.E.M.   found 1 times
X9SCL/X9SCM  found 6 times
*
 

 
>
>  On really old HP gear it doesn't work, 
>
> What does that mean? 
>
>
I meant that on our very old HP servers the PCI device name mapping doesn't 
come up, so you end up with eth0, eth1, etc.

 

> > We still need some sort of "glue record" that says "this interface 
> should 
> > be up and have this IP". In our older designs this was managed entirely 
> in 
> > Hiera - so there's a giant multi-level hash that we run 
> create_resources() 
> > over to define every single network interface. You can imagine the 
> amount 
> > of Hiera data we have. 
>
> That's what we're trying to avoid. Can you share example snippets? 
>


Here is a snippet of the older style, in a Node's Hiera. It is what I'm 
trying to move away from, because if you want to create 20 of these 
machines you've got to copy this Hiera hash around 20 times over. Oh the 
number of typos... You can probably interpolate the defined types that this 
data has create_resources() run over, the key names are pretty Red Hat 
specific:

***
networking::interfaces:
  bond1:
bonding_opts: mode=802.3ad xmit_hash_policy=layer3+4 lacp_rate=slow 
miimon=100
enable: true
onboot: 'yes'
type: Bonding
  bond1.3:
broadcast: 1.1.3.255
enable: true
ipaddr: 1.1.3.7
netmask: 255.255.255.0
network: 1.1.3.0
onboot: 'yes'
vlan: 'yes'
  p4p1:
enable: true
master: bond1
onboot: 'yes'
slave: 'yes'
type: Ethernet
  p4p2:
enable: true
master: bond1
onboot: 'yes'
slave: 'yes'
type: Ethernet
networking::routes:
  bond1:
device: bond1
routes:
- 1.1.2.0/24 

Re: [Puppet Users] How to handle predictable network interface names

[Rob Nelson]

We are provisioning everything with vmxnet3 drivers, only weird old OVAs
from vendors have non-vmxnet3, and we don't manage those with puppet. We
are cloning from template and getting the same results on different
vSphere/vCenter versions and instances. Not sure why they would come out
different since the "slot" ends up being the same on the virtual hardware.


Rob Nelson
rnels...@gmail.com

On Thu, Aug 25, 2016 at 8:30 AM, Marc Haber 
wrote:

> Hi Rob,
>
> On Wed, Aug 24, 2016 at 10:30:20AM -0400, Rob Nelson wrote:
> > We use VMware's vSphere, which still results in "random" but predictable
> > interface names - eth0 is now eno16780032, eth1 is now eno3359296, etc.
>
> In my experience, the numbers are rather random, different on each VM.
>
> > We've stuck with that because while it's somewhat painful (eth# is
> soo
> > much easier to comprehend), it's far less painful to memorize that than
> to
> > maintain some udev rules that may need tweaked across time.
>
> having net.ifnames=0 looks easier than working with those eight-digit
> numbers.
>
> >  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.
>
> Yes, that's what I'd see as a last moment manoeuvre. My gut feeling
> says "bad idea, don't do that". I don't have any evidence-based
> arguments for that though.
>
> 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/20160825123035.GZ2471%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/CAC76iT9xdN_CQZO8h9jvQZKMtsqKG8%3DfrJy_evxb-%2B_8_32hLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Key management with AWS S3

[Joseph Lorenzini]

Hi Mathew,

I've actually been wrestling with a similar problem myself. So far the 
solution I like the best is the following:

   1. use gpg encryption to encrypt the files on disk and then commit them 
   into the VCS.
   2. do NOT include the gpg private key or the passphrase for the key into 
   the VCS (that would defeat the whole purpose obviously)
   3. for automated deployments where a system requires access to the 
   cleartext data  do either 1)use an out of band provisioning mechanism to 
   push the key and passphrase to the node, decrypt the data, and then remove 
   the key and passphrase. or 2) gpg does support unencrypted keys (less 
   secure then two factor but still reasonably robust) so you could just use 
   that to encrypt the files and then just do a gpg import of the private key 
   on the system that needs the ability to decrypt the file.

Note depending on your security requirements you may need to use different 
keys to encrypt different files (one key to encrypt them is all is a much 
bigger attack surface then one key per file etc but the complexity of key 
management becomes far greater.)

Within that problem space, this tool looks really promising but i haven't 
had a chance to try it out yet.

https://github.com/StackExchange/blackbox

Joe 

On Tuesday, August 23, 2016 at 9:23:06 AM UTC-5, Matthew Denton wrote:
>
> Hey guys, 
>
> I was wondering if anyone has had success doing this? Currently, I have 
> private keys being stored in my private repo. I'd like to make my code 
> public but need to obviously do some scrubbing. I've heard of an 
> implementation where you store your keys in a S3 bucket then use puppet to 
> download the keys and use for config. I saw an s3 module but it required 
> the keys to access the keys. Curious how some of you handle this!

-- 
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/3b77f873-48ea-4e24-9086-14b28d33afbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to handle predictable network interface names

[Marc Haber]

On Wed, Aug 24, 2016 at 09:03:16AM -0700, Luke Bigum wrote:
> The template will create udev rules from two sources. The first is 
> @interfaces, which is the giant multi-level hash of network interfaces that 
> our old designs use. A VM might look like this in Hiera:
> 
> networking::interfaces:
>   eth0:
> ipaddr: 1.1.1.1
> hwaddr: 52:54:00:11:22:33
> 
> The second source of udev rules is also a Hash and also from Hiera, but 
> rather than it be embedded in the giant hash of networking information, it 
> is there to compliment the newer role/profile approach where we don't 
> specify MAC addresses. This is purely a cosmetic thing for VMs to make our 
> interface names look sensible. Here is a sanitised Hiera file for a VM with 
> the fictitious "database" profile:
> 
> profile::database::subnet_INTERNAL_slaves:
>   - 'eth100'
> profile::database::subnet_CLIENT_slaves:
>   - 'eth214'
> networking::extra_udev_static_interface_names:
>   eth100: '52:54:00:11:22:33'
>   eth214: '52:54:00:44:55:66'

So the "database" machine wouldn't have an entry in
networking::interfaces at all, or could one define, for example, the
management interface in networking::interfaces and the database
interfaces in the machine-specific hiera tree?

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/20160825123111.GA2471%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to handle predictable network interface names

[Marc Haber]

Hi Rob,

On Wed, Aug 24, 2016 at 10:30:20AM -0400, Rob Nelson wrote:
> We use VMware's vSphere, which still results in "random" but predictable
> interface names - eth0 is now eno16780032, eth1 is now eno3359296, etc.

In my experience, the numbers are rather random, different on each VM.

> We've stuck with that because while it's somewhat painful (eth# is soo
> much easier to comprehend), it's far less painful to memorize that than to
> maintain some udev rules that may need tweaked across time.

having net.ifnames=0 looks easier than working with those eight-digit
numbers.

>  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.

Yes, that's what I'd see as a last moment manoeuvre. My gut feeling
says "bad idea, don't do that". I don't have any evidence-based
arguments for that though.

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/20160825123035.GZ2471%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to handle predictable network interface names

[Marc Haber]

On Wed, Aug 24, 2016 at 09:20:56AM -0700, Luke Bigum wrote:
> Now that I think about it, I might be able to post a sanitised version of 
> the module online with most of the internal stuff stripped out. It might 
> prove useful for educating our own staff in the concepts, as well as other 
> people. It's not a 5 minute job though so if/when it's done, I'll write a 
> new Group post instead of continuing to hijack this one :-)

Thanks in advance!

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/20160825122621.GY2471%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to handle predictable network interface names

[Marc Haber]

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?

>  We have a 3rd party patch manager tool (patchmanager.com), LLDP on
>  our switches, and a Nagios check that tells me if an interface is not
>  plugged into the switch port it is supposed to be plugged into
>  (according to patchmanager).

Nice ;-) Is the code for the Nagios stuff public?

>  This works perfectly on Dell hardware because the PCI name mapping
>  works.

And you don't have many different kinds of servers.

>  On really old HP gear it doesn't work,

What does that mean?

> We still need some sort of "glue record" that says "this interface should 
> be up and have this IP". In our older designs this was managed entirely in 
> Hiera - so there's a giant multi-level hash that we run create_resources() 
> over to define every single network interface. You can imagine the amount 
> of Hiera data we have.

That's what we're trying to avoid. Can you share example snippets?

>  In the newer designs which are a lot more of a role/profile approach
>  I've been trying to conceptualise the networking based on our
>  profiles. So if one of our servers is fulfilling function "database"
>  there will be a Class[profile::database]. This Class might create a
>  bonded interface for the "STORAGE" network and another interface for
>  the "CLIENT" network.

That is interesting and a nice concept. But nothing one introduces
just to remedy an error report named "help, my interface names do not
fit any more".

So you do create network interfaces in the profile and not in the
role?

>  Through various levels of Hiera I can define the STORAGE network as
>  VLAN 100, because it might be a different vlan tag at a different
>  location. Then at the Hiera node level (on each individual server) I
>  will have something like:
> 
> profile::database::bond_storage_slaves: [ 'p2p1', 'p2p2' ]
> 
> That's the glue. At some point I need to tell Puppet that on this specific 
> server, the storage network is a bond of p2p1 and p2p2.

So you need to know when writing this code what kind of hardware the
system is running on, probably down to firmware version and hardware
extras?

> I have bounced around the idea of removing this step and trusting the 
> switch - ie: write a fact to do an LLDP query for the VLAN of the switch 
> port each interface is connected to, that way you wouldn't need the glue, 
> there'd be a fact called vlan_100_interfaces.

So the fact would be coming from the _server_ based on what lldpcli
show neighbors detail returns, which is supposed to include the VLAN
information? Would this work on 801.1q trunks as well?

>  Two problems with this approach: we end up trusting the switch to be
>  our source of truth (it may not be correct,

The switch uses its own source of truth which also influences which
network traffic gets sent down the link, so trusting the switch will
at least fail to the safe side and avoid accidentally putting full
trust on an Internet link.

>  and, what if the switch port is down?).

One would have to fall back to a certain safety net then.

>  Secondly the quality and consistency of LLDP information you get out
>  of various manufacturers of networking hardware is very different, so
>  relying on LLDP information to define your OS network config is a bit
>  risky for me.

Is it really this bad? I do have experience with HP and Cisco, and
their LLDP/CDP information is usually fine.

> It's a different story for our VMs. Since they are Puppet defined we 
> specify a MAC address and so we "know" which MAC will be attached to which 
> VM bridge. We drop a MAC based udev rule into the guest to name them 
> similarly, ie: eth100 is on br100.

How do you puppet define your MAC addresses? Which virtualization do
you use? Can i see a code snippet?

> That's what we do, but it's made easy by an almost homogeneous hardware 
> platform and strict physical patch management.

Yes. The homogenous hardware platform is probably something that can
only be maintained for really large installations.

> When I read about your problem, it sounds like you are missing a "glue 
> record" that describes your logical interfaces to your physical devices.

We're desperately trying to avoid having this in Hiera.

>  If you were to follow something along the lines of our approach, you
>  might have something like this:
> 
> class profile::some_firewall(
>   $external_interface_name = 'eth0',
>   $internal_interface_name = 'eth1',
>   $perimiter_interface_name = 'eth2'
> ) {
>   firewall { '001_allow_internal':
> chain   => 'INPUT',
> iniface => $internal_interface_name,
> action  => 'accept',
> proto