On Sunday, February 10, 2013 12:58:48 PM UTC-6, Roman Shaposhnik wrote:
>
> On Sun, Feb 10, 2013 at 9:32 AM, Keith Burdis <ke...@burdis.org<javascript:>>
> wrote:
> > Have you looked at using hiera [1] for your configuration? It is very
> good
> > for cascading defaults with more specific config at the top of the
> hierarchy
> > and the least specific at the bottom. It is part of Puppet 3 and an add
> on
> > for 2.7.
>
> Yes, I have looked at it. My problem with Hiera is that it resides
> completely
> outside of Puppet's DSL and is arguably pretty orthogonal to the
> parameterized
> classes API.
Separating configuration data from your manifests is precisely what Hiera
is for. The prevailing opinion around here is that that's a *good* thing.
Besides, if you want the data in Puppet DSL then you can just declare it as
variables of some class or classes. Or your ENC can set it as the values
of global variables.
Furthermore, Puppet 3 integrates Hiera with parameterized classes by using
hiera to look up values for class parameters that are not explicitly
declared, before ultimately falling back to any defaults written into the
class itself. There are good reasons to rely on that function completely,
instead of declaring parameters explicitly anywhere, though those reasons
are somewhat weaker if you use a custom ENC.
> I like parameterized classes precisely because they are
> dynamic. IOW, I can have my ENC instantiate classes with particular
> parameters depending on any criteria I want *without* affecting anything
> else on the system. If I want my cluster instantiated during odd numbered
> hours to have auth => 'simple' and the rest auth => 'kerberos' -- that's
> just ENC's job. If I want to pull off that same trick with Hiera --
> I'm essentially
> signing up to change a bunch of global variables that can potentially
> affect my entire site.
>
Is that a bona fide use case for you? That would be unusual.
In any case, if you rely on the Hiera integration with parametrized classes
then you can draw your data from Hiera under normal circumstances without
losing the ability to override via your ENC.
>
> That said, I'm starting to suspect that any solution to my problem that
> can
> be hidden inside of parsing step has to either be parsing order dependent
> (yuk!) or it has to rely on some global state that is guaranteed to be
> consistent
> before the parser takes over. Hiera fits that description, but it is too
> global.
>
I really don't understand what you mean by "too global". Hiera's
architecture appears to be an excellent fit for your "cascading defaults",
and as I already discussed, you can apply local overrides via your ENC in
the event that you actually need to do. It is also easy to define your
data hierarchy so that you can provide per-machine data where you want to
do that (or per-rack, or per-datacenter, etc., provided only that Puppet
can identify the target machines via their node facts).
> Perhaps I can simply teach my ENC to spew out the top-level parameter
> called cascading_defaults which would be a hiera-like hash for looking up
> those very same values. Then my params class could be made rewritten as:
> class cluster::hdfs::params {
> auth = hlookup('auth', $::cascading_defaults, ['cluster',
> 'hdfs'], 'simple')
> }
>
> Does it make sense?
>
>
That sounds like a workable solution, but whether it makes sense depends on
information I don't have. I am inclined to suspect, however, that you are
rejecting Hiera based on mis- or limited understanding of what it can do
for you. If Hiera can in fact do the job adequately, then I think it makes
the *most* sense to use it instead of building your own custom solution.
John
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
