On Wednesday, September 26, 2012 10:52:19 AM UTC-5, Guillem Liarte wrote:
>
> This is the situation I have:
>
> All my hosts are the* same OS.*
> All my host are in the* same puppet environment,* so I cannot use
> %{environment}
>
> I have a module that sets all the *basic* functionality for the OS,
> resolution, authentication, security, packages, etc
> I have a module for each application hosted.
>
> At the moment all the 'data' is in Puppet, mostly in parametrised classes
> in site.pp.
>
> What I want to get is a hiera set-up that allows me to use this structure:
>
I suspect that one of the reasons you are having trouble is that you are
trying to employ a usage paradigm that is inconsistent with hiera's design
(more below).
>
> :hierarchy:
> - global # source of application names (classes? modules?) and
> environments list
> - basic # data for the basic class
>
There's nothing wrong with those levels.
> - prod/%{application}/%{hostname} # hostname files for specific
> data
> - prod/%{application}/%{env} # environmental data for
> each application (module)
> - prod/%{application}/default # default data for an
> application
>
But there *is* a problem with those. It may be possible to make it work,
but it's shaky to use variable hierarchy levels for data *selection*.
That's what keys are for. With that said, recent Puppet releases provide
automatic $calling_module and $calling_class variables, one of which you
could probably use in place of $application. As I understand it, that's
intended to provide (better) support for module-specific data, which might
be a good way to cast that part of your problem.
> - nonprod/%{sysclass}/%{hostname}
> - nonprod/%{sysclass}/%{env}
> - nonprod/%{sysclass}/default
>
You additionally have a fundamental problem with %{env}. Hiera will
attempt to resolve that as a *Puppet* variable, to which the presence of a
matching key somewhere in the Hiera hierarchy is irrelevant. Hiera needs
to know the value to resolve the hierarchy (as you have defined it), and it
would need, in principle, to resolve the hierarchy before it could look up
the value in your data store.
What actually happens, I'm sure, is that hiera uses the value of $::env
that it looks up in Puppet at function entry. You might be able to work
around that by setting that variable in Puppet before looking up other
data, such as by putting
$env = hiera('env')
at top scope near the beginning of your site.pp.
> So in short, I would like hiera to be a source of facts, where I can get
> information that feeds Puppet in order to classify the nodes and to feed
> the parametrised classes.
>
As an aside, throwing parametrized classes into this mix has only downside
as far as I am concerned, except inasmuch as you may want to use
parametrized classes that are (unwisely) provided by modules written by
others. Since you want to rely on hiera (which is good), it is superior to
write your classes like this wherever you are in control of module
interfaces:
class mymodule::class1 {
$param1 = hiera('mymodule::class1::param1')
$param2 = hiera('mymodule::class1::param2')
# or with simpler keys enabled by use of
# %{calling_module} and/or %{calling_class}
}
There are several advantages, among them that you can encode interclass
parse-order dependencies via the built-in 'include' function, and that you
can use hiera's 'hiera_include()' function to assign such classes to nodes.
>
> I recently found this blog entry:
>
> http://garyhetzel.com/2012/04/12/hiera_as_a_puppet_enc
>
>
Gary appears to have done some cool work there, but as you have discovered,
it's not going to overcome the inherent problem with self-referrential
data. It might be possible to work around this by augmenting Gary's hiera
additions/modifications with a separate pre-lookup of needed extra
variables, but you're then talking about a distinctly non-trivial effort
and a substantial branch away from stock hiera.
I would like to make emphasis in this: Gary's hiera as an ENC works, but
> for a more simple scenario than the one I am proposing, if I only wanted to
> classify Classes and Hosts, it does work fine. Where I have not been able
> to succeed is in adding an 'env' layer after the application (classes,
> organised in modules).
>
You are classifying based only on hostname, because that's the only data
you want to consider that actually originates from the node being
classified. Everything else is logic and structure of the ENC you are
trying to build.
The problem is that you are trying to implement a data structure that Hiera
does not natively support. You can make it work, but you will need either
significant changes in hiera, or a different usage mode. I would suggest
the latter.
Were I you, I would consider writing a separate, hiera-based ENC instead of
trying to build all the ENC features you want directly into hiera itself.
Among other things, you would not then need to worry about maintaining a
private hiera fork. It looks like the basic idea would need to involve the
ENC making multiple (at least two) lookups in hiera, using possibly
different subsets of the overall data hierarchy for your site, to retrieve
the variables to and classes (optionally with parameters) that should be
assigned. Anywhere the assigned classes perform their own hiera lookups,
they would use the full hierarchy.
Although Gary's work doesn't do everything you want, it would probably
serve as a good guide to much of what is needed.
John
--
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/-/IT2oIrddP-QJ.
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.
