As a courtesy update for our user community:
My earlier claims about the "lookup" function were exaggerated. Instead,
the "hiera", "hiera_array", and "hiera_hash" functions will all be
available, provided by Hiera.
Also, as mentioned earlier, class parameters will be sourced from multiple
locations, with the following priorities:
- Hardcoded in the manifest (e.g. class { "foo": bar => "baz" })
- Supplied by an ENC
- Automatic namespaced data lookup in Hiera
- Class-specified default value
Feel free to ask if you have any further questions.
Thanks,
- Pieter
On Thu, May 3, 2012 at 10:05 AM, Pieter van de Bruggen <
[email protected]> wrote:
> 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:
>
> - Hiera data keys can be namespaced
> - (e.g. 'dns::nameserver': '8.8.8.8')
> - Namespaced data will automatically populate class parameters
> - (e.g. 'dns::nameserver' will be automatically looked up for the
> $nameserver parameter when you include dns)
>
> Here’s what’s changed:
>
> - The hiera-puppet module will no longer be required
> - It should, however, still continue to work
> - The heira() function (from the hiera-puppet module) will be
> superceded by the lookup() function (in Puppet core)
> - hiera_include() will not be ported; include now properly accept
> arrays, making this redundant
>
> Here’s what were still wondering about:
>
> - 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?
>
> If you’re interested in test-driving the new functionality for yourself,
> checkout out the master branch of the Puppet repository on
> Github<https://github.com/puppetlabs/puppet>,
> install Hiera (with gem install hiera) and make the following
> configuration changes:
>
> - Set data_binding_terminus to hiera
> - If you have a Hiera configuration file, set hiera_config to point to
> it.
> - If you don’t, create a file in ${confdir}/hiera.yaml with these
> contents:
>
> :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!
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
