Hi all, Thanks for the input
On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar <[email protected]> wrote: > > > ----- Original Message ----- > > > > > > > > On Mon, Apr 11, 2011 at 9:25 PM, John Warburton < > > [email protected] > wrote: > > > > > > OK, I'll bite > > > > In the newly published Style Guide ( > > http://docs.puppetlabs.com/guides/style_guide.html ), right at the > > end it says > > > > Modules should avoid the use of extlookup() in favor of ENCs or other > > alternatives > > > > > > For clarity, this should read: > > > > in favor of ENCs in combination with parameterized classes > > > > > > > > But there is no reason as to why. > > > > > > that is partly my fault. > > > > <the following is my opinion, and may or may not express the opinions > > of PuppetLabs, although I can be pretty persuasive :) > > > > > Extlookup provided some necessary pre-2.6.x functionality, namely, a > > sane way to get around dynamic scoping. > > This is not what extlookup is for. Yes it effectively works around the > Wacky Scope problems but that is not its reason for existing. It exists primarily to: > > - allow the data - lets call it the model - to live separate from the > code (controller?) and the templates (view?) > Let me clarify this: I understand this is not what extlookup is for, I was saying here that this is why is was 'necessary' pre 2.6.x (as a sane alternative to dynamic scoping), I apologize, because obviously my intent here was not clear . The kind of data modeling you mention has been possible with an ENC for as long as I have been using Puppet. > - it is easy to grasp, easy to train members of a team and with a bit > of discipline its trivial to look at a class and know how you can > configure it. > The fact that you have to look at the class to understand what data it accepts is my main complaint. I have not found parameterized classes problematic to teach, do you have some specific experiences around this? > - It doesnt require any code changes to change the way the data behaves > which is great for shared code like those found on the forge. Unlike > the layered class approach > I am not sue what you mean here > - To replace almost all case statements > I also agree that Puppet should have as little conditional logic as possible, I have recently been solving this with a combination of an ENC and ::param namespaced classes (an entirely different topic). > - To be an appropriate level of complexity for the average Puppet user. > Compare experiences in #puppet with newbies learning extlookup vs the > layered classes approach. I don't have any data related to this, but would be interested on further perspective. > Yes the layered classes approach is elegant > and less hacky but it is by no means understandable by newbies. > The last point is the big one, Puppet has always been a language for > sysadmins who want to automate their infrastructure. The layered class > approach is something that you only get once sat in a class and taught. > In this regard Puppet has lost its way. > That is a really strong assertion RI. We are doing our best to create reasonable practices that 'we' can use to create modules, we have shared our first reasonable version of those with the community so that we can work to make it better. > It is not awesome though, there are limits to how you can configure the > data the approach it takes isn't flexible enough really but it solves > most of the problems it set out to solve. You cant programatically figure > out what a class requires like you can with param classes if you dig > deep enough. I hope we do a better job of exposing those APIs in the future > So an alternative was proposed - Puppet Data Language[1] > that combines with param classes to address this properly. > > > > > given the option between parameterized class combined with an ENC vs. > > extlookup, I choose parameterized classes+ENC. The reason is > > readability and encapsulation. > > > > In order to understand an implementation of Puppet using extlookup, > > you have to understand all of your code in its entirety. After all, > > any code anywhere in your modulepath could be calling extlookup and > > accessing data. (I would be very interested to hear if anyone has a > > good pattern for this) > > > > With param classes, you can build a layered architecture of classes > > that pass data to each other through their explicit interfaces. > > How easy is it to adjust how you layer these classes? I do not understand this question > How sharable is > this set of layered classes with other teams, other business or event > entirely unrelated 3rd parties via the forge? this is one of the main reasons that I like param classes, explicit interfaces should make sharing/collaboration easier. > How many inheritance > related bugs have gone reported but never fixed? inheritance is not something that I recommend in general, although I would appreciate a short list of these are the broken things about inheritance. > How will the often > mooted changes to puppets internal scoping affect already written code? > How does layered classes sit with modules already on the forge? > This is an admitted problem, this document was written to outline some of the guidelines that we intend to use internally for module development, further consideration needs to be put into how these recommendations interact with existing implementations. > In my experience all of these are either unknown or very hard to answer, > its difficult to explain as a concept and it is not as flexible or > readable as extlookup is in the majority of the cases. > > These are the problems extlookup exist to address, not a scoping solution. > Extlookup replaces a case statement, its trivial to understand, its > easy to use and easy to configure. I think it's a much more suitable > solution for the average puppet user - a sysadmin - than a complex layered > almost OO approach that is favored by seasoned programmer. Our user > base simply isn't programmers and understanding complex OO concepts > is hard and we should do more to make it easier not harder. > > This is a known problem, and so Puppet Labs have spec'd the PDL[1] > to address these problems, without the PDL I do not consider param > classes very user friendly at all. > > The PDL is a *much* more desirable solution than either layered classes > or extlookup, why it has gone un-implemented I dont know and why the > current suggestion is that layered classes somehow represents an effective > alternative to the PDL I do not understand at all - since surely why > bother with the PDL at all then? > > Because a solution to creating easy to share, document and tweak - without > changing the code in the module - is needed and that is what extlookup and > the PDL aims to provide. > > It's a real shame that the PDL has fallen off the wagon and not getting > any attention since without it people are stuck with either spending > months becoming seasoned Puppet coders or just using extlookup. And > without the goal of getting a sharable set of modules written by normal > community members is still just a pipe dream. > > Other have been beating the layered classes drum for years, given talks > and presentations at it at each Puppet Camp and promoting their use and > they are not adopted widely because they are simply too complex and not > fit for the average community user. > > [1] http://projects.puppetlabs.com/issues/6079 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" 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-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users?hl=en.
