Puppet users - Sep 2014 - hiera - default parameter values and design questions

Hello all,

I ran into a problem with hiera and in particular, assigning or not 
assigning default values to variables within a data source.  I'm using the 
mcollective module (currently using version 1.1.6) and I've built a very 
simple hiera backend to start adding site-specific data into a single 
place.  Within the mcollective init.pp manifest, I've identified four 
places for which I'd like to abstract data into hiera; they are:

$server        = hiera('::mcollective::server'),
$client         = hiera('::mcollective::client'),
$middleware = hiera('::mcollective::middleware'),
$middleware_hosts = hiera('::mcollective::middleware_hosts'),

I've created a fqdn specific hiera source (ourlocalhost.local.yaml) and 
added this:

classes: 
  - mcollective

# mcollective parameters
mcollective::middleware: true
mcollective::server: true
mcollective::client: true
mcollective::middleware_hosts:
  - ourlocalhost.local

Upon running puppet on this specific host, the puppet run completes and I 
marvel at the wonder of puppet and heiras' beautiful co-existence.

Now I'd like to simply add mcollective to any node in my network so I go to 
common.yaml and add the following:

classes:
  - mcollective

# mcollective parameters
mcollective::server: true
mcollective::middleware_hosts:
  - outlocalhost.local

However, upon running puppet on a fresh machine, I get the following error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find data item ::mcollective::client in any Hiera data file and 
no default supplied at 
/etc/puppet/environments/test/modules/mcollective/manifests/init.pp:5 on 
node mynode.local

If I add this line into common.yaml (mcollective::client: false) then I get 
the following failure:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find data item ::mcollective::middleware in any Hiera data file 
and no default supplied at 
/etc/puppet/environments/test/modules/mcollective/manifests/init.pp:6 on 
node mynode.local

If I then go back into common.yaml and add 'false' to the values I
don't
want, everything works:

classes: mcollective
mcollective::middleware: false
mcollective::server: true
mcollective::client: false
mcollective::middleware_hosts:
  - ourlocalhost.local


I've been searching for answers on the interwebs and haven't been able
to
find anything specific for this one so I figured I'd ask a few questions:

1.  Is this the expected functionality?  If so, am I to understand that I 
have to keep track of every hiera call (ex $server = 
hiera('::mcollective::server'), $client =
hiera('::mcollective::client')),
in my many modules and create defaults for each of these values in the 
various hiera source files that I create?  My understanding was that I 
could create these hiera calls in my classes and a al carte these values 
within my hiera source files.  Am I mistaken and if not, doesn't that 
create redundant data within my hiera source file tree?  Also, if future-me 
adds one additional hiera call to the init.pp, does that mean I have to 
track down every hiera data source and add a default value to each one?  

Which brings me to my next question:

2.  It seems that things could get messy very quickly if I am declaring 
parameters via hiera (let's take this mcollective example) and I have 
multiple hiera source files for which these values are declared.  As an 
example, let's say I have a custom fact which determines that a node is a 
'server' based on hostname. I then create a hiera data source called 
'server.yaml' and assign the mcollective parameters to that data source
and
all is well in the universe.  

But if I later I want to create a custom hostname data source for that 
server called 'nodename.yaml' and assign parameters from that source, I
now
have two places to check for declared values.  Additionally, if I go to the 
mcollective init.pp file, I simply see the source for that variable is 
being called from hiera but since I have two data sources, how will 
future-me know which one to check?  Further more, if I have a colleague 
that is just familiar enough with our infrastructure to check the init.pp 
and indeed he/she sees that the data is coming from hiera, he/she won't 
know where to look if we've defined the data in our 'server.yaml'
our
'node.yaml' and our 'common.yaml'.  Obviously this is a
simplistic example
but am I thinking about this wrong?  Perhaps I've missed/overlooked a major 
piece of the overall hiera design?  Or, I'm simply a jackass and I'm
"using
it wrong?" 

3.  If I want to add multiple 'classes' to say, common.yaml, is there a 
particular way in which I should is the below structure the preferred 
method and if so, does hiera parse these from top to bottom or am I likely 
to run into resource ordering problems in the future?:

classes:
  - one class
  - two class
  - three class

# class one parameters
stuff
blah

# class two parameters
stuff
blah

# class three parameters
stuff
blah


Thank you in advance to whomever replies with thoughts as I realize this is 
quite a long post.

Cheers,

Mike

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1c26c35b-f0c0-4caf-9ef7-9dfb9070fc2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.