The question here is not really how to work around this but rather what the new feature should add instead of take away. The thing you do there with the 'inherits' is exactly the behaviour i 'expect' from hiera-puppet but less the 'inherits' call.
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.
