Greetings,
As many of you may be aware, Hiera will be tightly integrated into Puppet in the upcoming release of Puppet 3.0. As a final sanity check of this work, I’d like to open our current plan for integration up for feedback. This is particularly for feedback from existing Hiera users, but I hope to solicit good feedback from those not using Hiera as well.
The problem, as it currently exists, is that Puppet (core) has no good first-class mechanism for separating configuration data from manifests. Everything from $faked_namespaces__in__variable_names to specialty “params” classes have been tried, with varying degrees of success.
Hiera came along as another solution to this problem, and provided a useful abstraction for hierarchical data lookup, but life as a plugin meant that certain integrations were still difficult. Our aim in Puppet 3.0 is to tighten up these integrations (making Hiera more useful), provide first-class data separation solution (for those not already using Hiera), and to provide a simple and safe migration for those currently using Hiera.
Here’s what’s new:
Here’s what’s changed:
Here’s what were still wondering about:
If you’re interested in test-driving the new functionality for yourself, checkout out the master branch of the Puppet repository on Github, install Hiera (with gem install hiera) and make the following configuration changes:
:backend:
- yaml
:yaml:
:datadir: $confdir/data
:hierarchy:
- %{certname}
- %{environment}
- global
This sets up a default hierarchy that looks for values in ${confdir}/data, first in the ${certname}.yml file, then in the ${environment}.yml file, then in global.yml.
That should be it! Please, let us know if you're having trouble getting started, or if you have questions, concerns, thoughts, or opinions about any of this.
Thanks!
I think the plan was that there would be a priority order as below:
- someone wrote in a manifest: class{"foo": something => something}
- an ENC supplied the values for something on the class foo
- someone did "include foo" or class{"foo": } this would consult hiera
- if hiera does not have an answer it would default to "default"
This gives people with more complex needs than those matched by hiera
the ability to use ENCs and get exactly the data model they desire as
well as people who do not want any magical data lookup for some class
the ability to hard code values.
And at the same time it lets module authors provide out of the box
defaults that work without placing a load on module users where they
might have to read every class and set hiera values for every argument
before they can use a class if all they wanted was the default out of
the box behaviour.
Does this sound sane?
---
hiera_var:
user:
value: 'my_value'
$hiera_var = hiera_hash('hiera_var')
$sorted_var = sort(keys($hiera_var))
<% scope.lookupvar('module::params::sorted_var').each do |item| -%><% scope.lookupvar('hadoop::params::hiera_var')[item].each do |key,value| -%>
<%= user %> <%= key %> <%= value %>
<% end -%><% end -%>
----- Original Message -----
> From: "Pieter van de Bruggen" <pie...@puppetlabs.com>
<snip>
>
> * How should we integrate hiera_array() and hiera_hash() ?
> * How should we integrate hiera ’s “default” and “override”
> parameters?
> * How should we handle overlaps between data supplied by Hiera
> and data supplied in a parameterized class include?Given:
class foo($something="default") { }
I think the plan was that there would be a priority order as below:
- someone wrote in a manifest: class{"foo": something => something}
- an ENC supplied the values for something on the class foo
- someone did "include foo" or class{"foo": } this would consult hiera
- if hiera does not have an answer it would default to "default"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
With the integration of Hiera, is the extlookup functionality being deprecated?
If so, I would like to ask that the team add a Hiera backend for the existing extlookup data sources.
I know that it won't support hashes but it would help to break the view that Puppet routinely breaks existing functionality on upgrades.
As many of you may be aware, Hiera will be tightly integrated into Puppet in the upcoming release of Puppet 3.0.
Still have to *write* the YAML files.
On May 7, 2012, at 12:47 PM, Christopher Wood wrote:
> Wrapper script (similar concept for anywhere with a yaml reader):
If you want the same abilities that CSV has then this would be your YAML:
sysadmin: y...@your.com
nameservers: [1.2.3.4, 2.3.4.5]
just that simple, I think this is much clearer than CSV. If people really are