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.
