Hello, Volcane has explained it pretty well. What i was really looking forward to with Puppet 3 - Hiera was being able to create modules with defaults for different OS/Versions built right in via the hiera-puppet backend without any dependency on external hiera data thus creating real 'standalone' modules that don't target one single OS. The way it seems to be implemented 'forces' the addition and 'complicated' distribution method for modules to even remotely achieve this.
This implementation feels like a step back. Regards, Stefan Goethals. On Fri, Sep 7, 2012 at 7:13 PM, R.I.Pienaar <[email protected]> wrote: > > > ----- Original Message ----- > > From: "Andy Parker" <[email protected]> > > To: [email protected] > > Sent: Friday, September 7, 2012 5:53:34 PM > > Subject: Re: [Puppet-dev] Hiera-puppet with Puppet 3 - FakeScope > > > > On Fri, Sep 7, 2012 at 9:10 AM, R.I.Pienaar <[email protected]> wrote: > > > > > > 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. > > > > > > > The data bindings can handle that by having the Debian and Redhat > > cases in hiera (all of the facts are available to the data binding > > service) and then the class would have: > > > > class example($service = "UNKNOWN") { > > if ($service == "UNKNOWN") { > > fail("Please specify a service name") > > } > > } > > > > I don't think this is quite as clear as the data class form, since > > there is now no single place to look to understand the behavior. > > this assumes everyone has operating system hierarchies, the data class > example specifically makes the class multi os aware regardless of whatever > hierarchies users have provided. > > In your example you'd either need to have a similar case in the example > class - thus coupling the data processing into the logic class - or > force everyone to have OS hierarchies AND supplying all the data you > need. > > The point of a in-puppet hierarchy is that it's there by default and > works by default as a last resort in the case that a user doesn't provide > the data. > > It's also a good crutch in the case where people want to do crazy logic > on their data using complex if/case/math which they couldn't do using the > yaml/json/whatever data sources as those clearly can't contain any kind > of logic other than that provided by the fact based selection which is > roughly equivalent to a case statement > > consider: > > class exim::data { > $deliver_queue_load_max = $cpu_cores * 1.2 > } > > Here we want exim to not deliver mail when the server is too loaded > but what defines 'too loaded' depends on the amount of cores the machine > has. It would be pretty painful to express this in pure-data hiera > as you'd need to dedicate an entire hierarchy to the amount of cores > present, quite a pain > > I'd think the only sane alternative is: > > class example($service=$example::data::service) {...} > > which roughly achieves the same as the hiera-puppet backend in this > specific example, not particularly nice though I'd think we can do > better > > > > > > >> 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. > > > > > > > True. And the data bindings are trying to take a next step in that > > direction. > > > > > 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. > > > > > > > I'm not sure if we want to remove it yet, since it still works and a > > lot of people are still using it. We would probably deprecate it > > first. I would only want to do that if there was enough consensus > > that the data bindings provide enough of an alternative solution. > > > > So we are going to continue supporting the puppet backend via the > > hiera functions. The data bindings will "work" with it in the sense > > that it doesn't blow up (as it did the first time we tried a setup > > with it enabled). At some point during the 3.x cycle it will probably > > be deprecated as it becomes clear that its use cases are covered by > > the data bindings, which might take some changes to the data > > bindings. > > OK > > -- > 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.
