[Puppet Users] Re: Making a "role" fact work

2016-02-01 Thread jcbollinger
On Friday, January 29, 2016 at 9:50:50 AM UTC-6, Gareth Humphries wrote: > > ENC is the end game, but we have legacy hosts this has to work on. Right > now I have site.pp which has a list of unpleasant regexes and an 'include > role::' stanza for each. I could put '$role= ; > include role::$

Re: [Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Gareth Humphries
t; > > To: "puppet-users" > > > Sent: Friday, January 29, 2016 5:14:12 PM > > Subject: Re: [Puppet Users] Re: Making a "role" fact work > > > Normally, yes, but in this case it needs a class list locally to > populate > > the fact, and it

Re: [Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread R.I.Pienaar
- Original Message - > From: "Gareth Humphries" > To: "puppet-users" > Sent: Friday, January 29, 2016 5:14:12 PM > Subject: Re: [Puppet Users] Re: Making a "role" fact work > Normally, yes, but in this case it needs a class list locally to

Re: [Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Jason Slagle
On 1/29/16, 11:14 AM, "Gareth Humphries" wrote: Normally, yes, but in this case it needs a class list locally to populate the fact, and it doesn't have that until after a run. Facts get sent to the master, where classes are allocated and a catalog compiled, then the catalog sent back to the cl

[Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Gareth Humphries
Thanks Luke, I'll give that a whirl. May prove helpful indeed! On Friday, January 29, 2016 at 4:07:42 PM UTC, Luke Bigum wrote: > > This might be relevant: > > > https://groups.google.com/forum/#!searchin/puppet-users/luke$20bigum|sort:date/puppet-users/XWAcm152cyQ/P_rpi50XBAAJ > > The ENC above

Re: [Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Gareth Humphries
anuary 29, 2016 at 3:53:54 PM UTC, R.I. Pienaar wrote: > > > > - Original Message - > > From: "Gareth Humphries" > > > To: "puppet-users" > > > Sent: Friday, January 29, 2016 4:50:50 PM > > Subject: [Puppet Users] Re: Making a

[Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Luke Bigum
This might be relevant: https://groups.google.com/forum/#!searchin/puppet-users/luke$20bigum|sort:date/puppet-users/XWAcm152cyQ/P_rpi50XBAAJ The ENC above inserts a top scope variable into a node's manifest, designed to be used as a "role" Fact. It reads from one of two YAML files, either expli

Re: [Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread R.I.Pienaar
- Original Message - > From: "Gareth Humphries" > To: "puppet-users" > Sent: Friday, January 29, 2016 4:50:50 PM > Subject: [Puppet Users] Re: Making a "role" fact work > ENC is the end game, but we have legacy hosts this has to work on. R

[Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Gareth Humphries
ENC is the end game, but we have legacy hosts this has to work on. Right now I have site.pp which has a list of unpleasant regexes and an 'include role::' stanza for each. I could put '$role= ; include role::$role' in each of them instead, but I would have to do that in every single case, whi

[Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread jcbollinger
On Friday, January 29, 2016 at 3:29:29 AM UTC-6, Gareth Humphries wrote: > > Thanks Gav, > > It's a good idea, though on the surface I don't think it will work for us > (we're trying to spin stuff up from a gold image using an ENC, and I think > having an extra magic step in between is a greate

Re: [Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Gareth Humphries
Hi Dirk, That's a good idea, thanks. In our case we have a lot of legacy hosts and no good naming convention - combined with an eye to a future of cloud-bases services (with undefined hostnames), and I think in our case that approach won't be maintainable. A good solution without those constra

Re: [Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Dirk Heinrichs
Am 29.01.2016 um 13:03 schrieb Gareth Humphries: > Any ideas? Can you derive the role from the hostname? I do something similar to determine the location of a machine based on IP address range. So I have lib/facter/location.rb in one of my modules, with the following content: # Set location of a

[Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Gareth Humphries
I've made some good progress, and am agonisingly close. I have the below code which extracts the role into a variable (ugly, but it works). I had kinda assumed that Facter.Add would work server-side, but I've discovered that it doesn't. So now, my problem is simple how to make a string calcul

[Puppet Users] Re: Making a "role" fact work

2016-01-29 Thread Gareth Humphries
Thanks Gav, It's a good idea, though on the surface I don't think it will work for us (we're trying to spin stuff up from a gold image using an ENC, and I think having an extra magic step in between is a greater evil than explicit declarations), but you've got me thinking down some other lines

[Puppet Users] Re: Making a "role" fact work

2016-01-28 Thread Gavin Williams
Gareth I've been working through the same issue internally here for a new Cloud based platform, and came up with the solution of pre-loading the machine with the role at the point the machine is provisioned. Then when it first checks in with Puppet it's already for the fact present... Might

[Puppet Users] Re: Making a "role" fact work

2016-01-28 Thread Gareth Humphries
Follow-up - I've managed to extract the node definition which includes the top level classes ("settings" and "role") - I'm presently working on how to extract the data I need from that. I lookup the node with: node=Puppet::Node.indirection.find( lookupvar('fqdn') ) Which works, and if i pp()