----- Luke Bigum <luke.bi...@lmax.com> wrote:
> On 18/05/12 04:04, Dan White wrote:
> > In a posting a few days ago was this hiera.yaml source listing:
> > ---------------------------------
> > :backends: - json
> > :hierarchy: - %{fqdn}
> > - %{lmax_role}_role
> > - %{lmax_env}_server
> > - %{pop}.tradefair
> > - common
> > :json:
> > :datadir: - /etc/puppet/private/
> > - /etc/puppet/environments/%{environment}/hiera_data_store/
> > - /etc/puppet/environments/%{environment}/rebirth_data_store/
> > -
> > /etc/puppet/environments/%{environment}/satellite_system_groups/
> > ---------------------------------
> >
> > I am curious how one might utilize this configuration.
>
> Hi Dan,
>
> That's my own terrible modifications to Hiera to support multiple data
> stores of the same type. Code is here, but I warn you, I hacked in the
> quickest way to get the functionality I wanted. I only modify
> hiera-json, would be simple to do any others though:
>
> https://github.com/lukebigum/hiera
> https://github.com/lukebigum/hiera-json
>
> As for use cases, a more elegant description is in this feature request:
> http://projects.puppetlabs.com/issues/13954
>
> > Can the same key value appear in more than one datadir ?
>
> Yes, but precedence is taken just like Hiera's natural hierarchy, so
> data stores at the start of the array have higher priority. In my case
> for example, "hiera_data_store" overrides "satellite_system_groups".
> > Or does one use the multiple datadir's to group keys in some fashion ?
> >
>
> That was the the original idea of the hack - I had data coming from
> several places - some JSON written by hand, some generated by scripts
> (the 'satellite_system_groups' store is a dump of our old Red Hat
> Satellite System Groups and 'rebirth_data_store' is procedurally
> generated). I could have modified the generating scripts to read any
> existing JSON and write out a merged file, but I was rushing and I
> didn't think of that at the time ;-)
>
> It has managed to keep a nice logical separation of types of Hiera keys
> though and you can put your data stores in different locations, like
> having a 'private' dir for password hashes that's not under revision
> control. This leads to giving our Development team a Git repo that's the
> lowest priority data store and allow them to specify their own keys to
> configure their Dev servers. Any Admin still has the ability to
> overwrite any key in an data store above it, so it stops them doing
> anything silly like changing passwords, LDAP servers, etc, as these keys
> will already be set by us (Admins).
>
> -Luke
Thanks for responding, Luke.
This looks like a useful expansion of the hiera back-end, but as I am still
fairly new to Puppet (and Python and Ruby for that matter), I think I will wait
for this to be formally accepted and incorporated before trying it myself.
One parting question: Is the :hierarchy: repeated in each mamber of the
:datadir: ? Logically, it should repeat, but I'd rather ask and be certain.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
--
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.
