On 5 May 2012, at 17:26, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:
> -----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. The hiera-puppet project provides a script to convert extlookup CSV to json or yaml, using that to migrate would be my preferred way with the extlookup function logging deprecation warnings If this reflects the actual plan I don't know, I did expect the people working on the merging project to engage on this thread more since they know best and there seems to be a few points for discussion here already that needs clarification > > Thanks, > > Trevor > > On 05/03/2012 01:05 PM, 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! >> > > - -- > Trevor Vaughan > Vice President, Onyx Point, Inc. > email: tvaug...@onyxpoint.com > phone: 410-541-ONYX (6699) > pgp: 0x6C701E94 > > - -- This account not approved for unencrypted sensitive information -- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQEcBAEBAgAGBQJPpVScAAoJECNCGV1OLcypcesIAJT9gARlmQNxR7ftUo4soR1r > R2aCh/k2B+Wylj/xfF3o9j3gZh/1WrOLogMGThNgYT9Vcv50zCcbeFjbCTVr2bBo > 18gtlcoJhTBeUebBk6CsFsG+sIApwja3UDbpSm49FRquCK/KI+fBV8gHhAQt9fgm > 1P0ZXB1KU61nhqrLEpHNRmJVKBvLCwDuqEMJltMuGoysczWEv0uVROtYari1T3g+ > tNqov2EkSj5NV+Au5DeNNKviToEDn+wR7JvtXEqRdwSc142U9PnZwp8MvM+/i2+W > RGKqg8HZuMMLEbbSnimdRnS6pCwKdgVJDPwBb+CoiZJJ0ftWCF2F9lNDjgUNjcI= > =/h12 > -----END PGP SIGNATURE----- > > -- > 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. > > <tvaughan.vcf> -- 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.
