----- Original Message ----- > Hi all, > > Thanks for the input > > > On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar < r...@devco.net > > wrote: > ----- Original Message ----- > > > > > > > > On Mon, Apr 11, 2011 at 9:25 PM, John Warburton < > > jwarbur...@gmail.com > 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.
Solving this problem with an ENC is suitable for people who can program. You are saying 'puppet cannot do this on its own, please write a whole bunch of code in $language to address the shortcoming' is this the message to send people who do not want to pay someone to come write that ENC? In the context of the question: do we use extlookup to solve this problem or do we use an ENC to solve the problem. Your answer here is extlookup isnt needed, just write your own ENC. I am saying this is a very un newbie friendly message to send to the user base when there is a way to solve the problem now while puppetlabs works on either a good ENC that we can download or work on finishing the PDL. > - 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. today, the day your recommendations are up there for everyone to adhere to and the scope of the question from the OP, this is no different with parametrized classes. There is no released introspection tool, there is no ability in dashboard to just ask the information it needs, to use a paramterized module, u need to open its classes and look at its params. Is this not the case? You seem to say here's a set of recommendations for how to use puppet, we think this is how you should do it and our reasons for saying so is that there's a bunch of unreleased features that makes it awesome. > I have not found parameterized classes problematic to teach, do you > have some specific experiences around this? No hard evidence, gut feel is if you go ask in #puppet or get together a representative group of people who have not been trained by PL you will probably find param classes are in very minimal use because they are a solution looking for a problem today - because the full picture isnt clear without PDL and so forth > > > - 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 You can just configure your data source to behave in line with local policies - not change the code. Which means if you cloned code from elsewhere the fork is a clean clone rather than a fork. Changing data vs rewriting code is very important from a change control point of view etc > 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. the recurring recommendation is to use a ENC. There is no decent ready to use ENC that people can just download - dashboard isnt great yet. So in order to use Puppet today and get strong data modeling you have to be a team who can *program* an ENC, the kind of team who can think about abstract concepts like layered data and modeling of real world objects into data. Turning this model into a full featured ENC that integrates with a database is a skill that systems administrators lack. ENCs are your hammer of choice to attack all problems because you are a good programmer - or devops or whatever - we used to have a good story for non devops people, today the recommendation is to just write your own ENC If all the user needs is to model data you are saying dont use extlookup to solve this problem elegantly and out of the box without any further development. Instead learn to program (or pay for support) and write your own data model system. This is a huge barrier to entry. also from your other mail: > I agree with this. One huge problem with this recommendation is that > we have still not shipped a feature complete ENC that can serve as a > replacement to the data modeling that extlookup provides. This > argument would be a lot more compeling if it was "use param classes, > and Puppetlabs super cool ENC". I have spent some time working with > customers to explain how to build these, and I have been working on > one that supports the model that I have in mind... This demonstrates the problem. You have had to spend time working with customers to explain how to build these. It's a very complex subject, something our target audience in many cases dont get. They do understand extlookup though and it does solve a high % of their problems *today*. So why make their life harder. I too want to see a better ENC and PDL launched, I also want to see param classes maturing into something truly usable. they are not yet this though, so why recommend users shoot themselves in the foot by not using the existing tools that is out there today to solve their problems today. You seem to skim over the bits of this mail about the PDL, would be good to get your views on how the PDL relates or do you think it shouldn't exit? > > > > 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 correct, _in the future_ its not there yet, to use param classes you need to edit the file and look at it. Just like with extlookup. Where's the win today? > > 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 having first modeled my data into fqdn and DC specific, I now want to add a new layer into my layered classes hierarchy to expose per country data this is a trivial change in extlookup and PDL, its much harder with a layered class approach > 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. *should* make it easier, but does it really? People need to study every class and understand every parameter, and then declare all those parameters and model the data today. Why have we not seen a huge explosion of reusable modules on the forge since 2.6 came out? Because without a data solution its not a solved problem. Tomorrow they might just use the PDL and all the pain will go away, this is what is the ideal scenario, but I feel recommendations being made to the community should reflect the present and evolve with the tool set so the community can discover the improvements you make. Your style guide is effectively a roadmap for how Puppet might one day work, not for how it works well today. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
