On Tue, Apr 12, 2011 at 11:24 AM, R.I.Pienaar <r...@devco.net> wrote:
> > > ----- 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. > I completely agree that this recommendation is a little lacking without an existing ENC to back it up. > > - 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, > It is a little rough around the edges, but there I have released (or at publised code for) an introspection tool (its just not very well advertised), It probably has a few bugs, and I am happy to address those via github issues. https://github.com/puppetlabs/interface-utils have a look at parser get_classes it needs a little polish, but it works against 2.6.5 or higher this tool relies on an existing indirector (resource_type) which should have this functionality built-in in Statler http://projects.puppetlabs.com/issues/6851 > 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? > have a look at: puppet dashboard import_classes --dashboard_path-/usr/local/dev/puppet-dashboard from the same repo. This is admittedly a prototype and something not ready for prime-time, I just want to highlight that I understand these concerns and am actively working to address them. > 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. > This may be the major point of confusion. This document was written internally to specify how we will be writing modules. We are sharing it with the outside world b/c we try to be open. As we develop our internal modules, it is reasonable that we can write tools to make the process easier or improve Puppet to make the process easier. There is perhaps one point that we missed in this process: if we choose a path that is forward looking and not how people currently develop modules, then how are they going to use these modules, this is something that needs a little more effort. > > 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 > I agree, although I think param classes also achieve this > > 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. > I agree that a working ENC to model these recommendations is clearly lacking, I have been working on one... > 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 > valid point > 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? > I was kind of hoping you wouldn't notice that :) I have an alternative in mind to the PDL that consists of - a kick ass ENC - param classes - param namespaces - a slight abuse of inheritance I would like to see language changes in Puppet to be able to differentiate between containers for data vs. classes that just specify the data for classes. I need to put more time in the problem-space before I feel very comfortable saying more than 'I have this experimental idea that I think will resolve the needs for PDL.' I don't want to be overly out-spoken in these ideas b/c I am in the thought minority here at PL on this topic. Perhaps we can spend some time Puppetcamp week to go over my thoughts on this. I have most of the model in my head, except the part where param classes create the additional complexity of having to map data inputs to data identifiers explicitly. > > > > > > > > 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 > In my mind, this layering of data occurs in the ENC, I have this model in my head (well there is some source code too) where you create data categories, and specify the override precedence for those categories. In this model, adding a new category should be easy as generating the data, editing a config file (or GUI), and establishing node assignment to categories. This is an example where I have helped a few customers create this model with one-off ENCs. Below is an example of the config file: categories: - env - site - application - role - version override_paths: - 'site/${site}' - 'site/${site}/${env}' - 'app/${application}' - 'app/${application}/${env}' - 'app/${application}/${role}' - 'app/${application}/${role}/${env}' - 'app/${application}/${role}/${version}' where each node is assigned to a single value for each category. the override_paths use the category values for a node to determine which data sets (in this example YAML files) should be used to build the final list of variables and classes where the data is merged with highest priority at the bottom of the list (which everyone finds confusing, but it is how my brain works) I would like to get the model of categories, how data maps to categories, how classes map to data, and how nodes map to categories/classes/data refined enough where I can build a command line interface at some point, but free time is not my friend right now. > > 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. > > -- 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.
