----- Original Message -----
> From: "Andy Parker" <a...@puppetlabs.com>
> To: puppet-dev@googlegroups.com
> 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 <ste...@zipkid.com>
> 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.
> separate data from code. The data bindings do this by extending the
> language and providing an extension point in puppet where you can
> plug in your own data lookup services. The puppet backend was a hack that
> depended on knowledge about puppet that leaked through to the
> implementation of the backend, which was never supposed to be
> available. We made the decision to not continue leaking this
> information in the data bindings code so that it would be less tied
> to the internals of puppet. That had the effect of cutting off the
> puppet backend, which we did not consider a problem since we wanted to
> promote the pure data bindings going forward.
I think the puppet backend far from being a hack was actually a major
win for module authors and our ability to create reusable modules that
work out of the box.
I think the 'hack' aspect comes from the fact that puppet doesn't cleanly
expose some of the data this backend would need hence the fake scope thing
but conceptually I think if it was realised better this backend still has
solid reason to exist and function
Either way, if we are not going to support a puppet backend the pull
request 1111 needs to remove that backend.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
