----- Original Message -----
> From: "Jeremy Carroll" <jer...@klout.com>
> To: puppet-users@googlegroups.com
> Sent: Friday, May 4, 2012 5:19:37 PM
> Subject: [Puppet Users] Re: Puppet 3.0 and Hiera
>
> 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. Chef has a lot of work for Deep
> Merging ordering that I believe Hiera would benefit from.
Do you mean you want the hierarchy to be standardised?
can you expand this with examples please?
> * 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.
Unfortunately ruby hashes has no order so we cant sort the hashes for you :(
Things are improving in 1.9, but I do not think there is much we can do there
>
>
> 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('hadoop::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 , 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/-/GxVliXSX5u0J .
> 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.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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.
