On Mon, Sep 10, 2012 at 3:33 AM, Stefan Goethals <[email protected]> wrote: > The question here is not really how to work around this but rather what the > new feature should add instead of take away.
The new features adds the ability to have data looked up by a fully qualified name. This allows module authors to ship defaults with the module and module consumers to use another system to redefine what those defaults should be in their environment. > The thing you do there with the 'inherits' is exactly the behaviour i > 'expect' from hiera-puppet but less the 'inherits' call. > Is making it more explicit in this manner a bad thing? It seems to me that keeping things more explicit like this is mainly an improvement because it doesn't hide as many details. > Regards, > > Stefan. > > > On Mon, Sep 10, 2012 at 11:26 AM, Erik Dalén <[email protected]> > wrote: >> >> On 7 September 2012 18:10, R.I.Pienaar <[email protected]> wrote: >> > >> > >> > ----- Original Message ----- >> >> From: "Andy Parker" <[email protected]> >> >> To: [email protected] >> >> Sent: Friday, September 7, 2012 4:58:17 PM >> >> Subject: Re: [Puppet-dev] Hiera-puppet with Puppet 3 - FakeScope >> >> >> >> On Fri, Sep 7, 2012 at 1:36 AM, Stefan Goethals <[email protected]> >> >> wrote: >> >> > Hello, >> >> > >> >> > "This is a known limitation and the data bindings were not >> >> > meant to support the puppet backend." >> >> > >> >> > ??? Can you elaborate on this please ? >> >> > >> >> > The puppet backend just makes Hiera awesome for supplying defaults. >> >> > Puppet not supporting the puppet backend for Hiera sounds weird to >> >> > me. >> >> > >> >> >> >> You are right that it allowed a way of supplying defaults that didn't >> >> have to live inside the class, but that is the same problem that the >> >> data bindings are trying to solve. With the puppet backend you would >> >> have done: >> >> >> >> class example::data { >> >> $var = 'foo' >> >> } >> >> >> >> class example($param = hiera('var')) { } >> >> >> >> That will still work. The point of the data bindings, however, was to >> >> get rid of these explicit calls to hiera. So now you can just put the >> >> default inline: >> >> >> >> class example($param = 'foo') { } >> >> >> >> That way there is no tying of the manifest code to Hiera. Module >> >> authors can put sane defaults in for parameters, and consumers of the >> >> module can use data bindings to set a value for them. Both the puppet >> >> backend and the data bindings were trying to achieve similar ends: >> > >> > this makes sense in the simple case. >> > >> > but what if you had something like this: >> > >> > class example::data { >> > case $::ofamily { >> > "RedHat": { $service = "httpd" } >> > "Debian": { $service = "apache2" } >> > default: { fail("Please specify a service name using hiera") } >> > } >> > } >> > >> > Here we clearly model different behaviours depending on the context and >> > clearly state what we do not support via default but still alow the >> > module user to then decide they would provide this override data >> > through whatever hierarchy make sense for their site, ENC or just >> > hardcoding it. >> > >> >> Can't this be solved by this pattern: >> >> class example::params { >> case $::ofamily { >> "RedHat": { $service = "httpd" } >> "Debian": { $service = "apache2" } >> default: { fail("Please specify a service name using hiera") } >> } >> } >> >> class example ( >> $service = $example::params::service >> ) inherits example::params { >> ... >> } >> >> Which has the benefit of working in 2.6.3+ and not just 3.0+ >> Might not look as nice though. >> >> -- >> Erik Dalén >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" 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-dev?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" 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-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
