On Sunday, January 15, 2012 12:41:50 AM UTC+1, Nigel Kersten wrote:
>
>
>
> What would it take for you to just have one source of truth for data
> Alessandro?
>
> e.g. what would we have to change about Puppet for us to simply use Hiera
> ?
>
> We're looking to integrate Hiera into Puppet for Telly, and in general
> moving data outside of manifests has a lot of benefits, but I'm interested
> to know whether you're of a similar mind with regard to the data you're
> considering.
>
Nigel,
first of all do consider that I don't exclude Hiera's use in this approach.
It's a choice, you can use Hiera to assign values to top scope variables
or directly when you call parametrized classes, actually where and how you
give values to variables is not forced by the module.
The reason why I didn't place hiera lookups directly in the module is that
these "nextgen" modules are supposed to work for Puppet > 2.6 and not
everybody might want to use it or have integrated Hiera in their setup, but
if the same modules can provide out of the box whatever is needed to work
seamlessly, I've no problems with that. (see third point).
Second point is that some variables, which are typically module's internal
variables (names, paths and so on), should be IMHO provided by the module
itself (the typical stuff for params class), to give some extra value
(cross operating system support) to the module and preserve the user from
providing this kind of common and preset data.
I do present also these variables as class parameters because I need a
quick way to pour all the modules variables (both "internal like these and
the ones the module's users is likely to provide) to some place on the
target system (for the puppi stuff, but actually once you have them in a
yaml file you can use them in other ways). To do this I use Ken's neat
get_class_vars () function.
At the same time there are some rare cases when a user may need to supply
these variables (for example paths and names for a custom package), so it's
not bad to have them as parameters available in the class.
Third point is that actually I would love to use Hiera directly in the
module (or better something that fallbacks to Hiera... see below) if there
would be a backend that permits something like what Dan has suggested me
(sorry for public quoting Dan, but I think your suggestions deserves wider
attention):
---QUOTE----
Instead of having to code all of the logic for how to perform the lookups
for all of the data in the params namespace(this is a lot of code!), I
would recommend using hiera (or another function) and coding the class
inclusion, and data lookup precedence in a custom backend.
I have a feeling that if you do a good enough job on the backend, it could
just become the default puppet hiera backend.
I imagine it working something like this:
when looking up a variable $var
class foo::bar (
$var = als_hiera($var)
) {
}
It does the followins:
- if the parameter was set in the class declaration, that always wins
(this is just how Puppet works)
- if an explicit class parameter was not set, the hiera function is
called, and does the following:
1. Look for a variable called $::foo_var ($::${module_name}_var)
2. Look for a variable called $::var
I like this capability of being able to set common behaviors across modules
with a single topscope variable, I do think this needs to be configurable
somehow:
$var = als_hiera($var, {'topscope_lookup' => false})
since this pattern may not be desirable for certain parameters
3. If the class params::foo (::params::${module_name} exists, include it
and look for the variable:
::params::foo::var
4. if the class ::foo::params (:$module_name::params) exists, include it
and lookup the value of the variable:
::foo::params::var
--- QUOTE ----
To this I might add that it would be nice to have the option to set a
default value if none is provided in the above sources:
var = als_hiera($var, {'default' => "mydefault"})
So, to reply to your question, Nigel, something like a hiera backend or a
Puppet function that does what is written before in any Puppet setup would
be what I need.
The ideal, maybe, would be a simple function that does the above and then
if Hiera is in place, uses Hiera without requiring it: I really would like
to reach a scenario where a person picks a single module and eventually the
dependent modules (stdlib and so on), and can use it on his Puppetmaster
without the need to introduce Hiera on it, if it's not already there.
This, at least, until most of the people will have a PuppetMaster with
integrated Hiera ... till that moment I would like to have modules usable
in the widest range of Puppet setups possible.
A similar function would be more than enough for me to throw happily away
80% of the code that is
in https://github.com/example42/puppet-openssh/blob/master/manifests/params.pp
All the best
al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/l1YoNqgCGqsJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
