We use Hiera backed Puppet here at Klout. Mainly for the reasons
of separating configuration data from puppet modules. We have had great
success, and I welcome this change to puppet core. Reminds me of some of
Chef's "Deep Merge" functionality. Here are a few of my thoughts.
- Name spacing variable names is a welcome improvement. It will help
with variable name collisions we have experienced (Ex: module1::hosts,
module2::hosts). We currently use the %{calling_class}, %{calling_module}
method
of scoping hiera variables.
- I currently like the flexibility of defining my own order for merging
of variables in hiera.yaml. But I would like Puppet to formalize the merge
order so everybody can use the same style when creating modules for reuse.
Also have some methods to specify overrides instead of merging from top to
bottom for hashes / arrays. Helps for configurations for systems that don't
want to inherit everything. Something like this.
- overrides
- hieradata
- module default params
- hiera_hash would be improved by sorting the hash natively. We
currently repeat this pattern every time we use a hiera hash. We create a
sorted array of each hash key, then iterate over the array to lookup values
in the hash. If we fail to do this, puppet run re-orders the file every run
as hash orders are not guaranteed. This causes a lot of un-necessary work
and change notifications. Example below.
*hieradata*
> ---
hiera_var:
> user:
> value: 'my_value'
*module/params.pp*
> $hiera_var = hiera_hash('hiera_var')
> $sorted_var = sort(keys($hiera_var))
*module/template/sometemplate.pp*
> <% scope.lookupvar('module::params::sorted_var').each do |item| -%><%
> scope.lookupvar('module::params::hiera_var')[item].each do |key,value| -%>
> <%= user %> <%= key %> <%= value %>
> <% end -%><% end -%>
On Thursday, May 3, 2012 10:05:14 AM UTC-7, Pieter van de Bruggen 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 view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/JUwQTdQzdlMJ.
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.
