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
But there is no reason as to why.
We have a rule of thumb where we use the ENC to set specific information for
a host, and extlookup for groups of servers (based on class, location, etc
set in the ENC). It works well, and we even received a thumbs up in a recent
Puppet Labs audit of our manifests as we have clear separation of
configuration and data.
So, why should we avoid extlookup()? What should we use instead?
John
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Mon, Apr 11, 2011 at 9:25 PM, John Warburton <jwarburton@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. 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. This means that in any given layer, you only have to understand the specified class interfaces and not their internals. It should be clear from the interface how data effects the behavior of a class. At the highest level, you can build composite classess that expose which data can effect the behavior of all of your Puppet code. class { ''myplatform'': ntp => ''foo'' foo_data => ''foo'' foo_server => ''''foo } class { ''myapp'': appvar1 => ''1'' appvar2 => ''2'' } Allowing you to have a single view of how data effects the behavior of your configuration components. as an added benefit, using an ENC with param classes maintains the classes together with all of their passed parameters in $yamldir/node/ for the last run of each node I look forward to further debate :)> We have a rule of thumb where we use the ENC to set specific information > for a host, and extlookup for groups of servers (based on class, location, > etc set in the ENC). It works well, and we even received a thumbs up in a > recent Puppet Labs audit of our manifests as we have clear separation of > configuration and data. > > So, why should we avoid extlookup()? What should we use instead? > > John > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- Original Message -----> > > > On Mon, Apr 11, 2011 at 9:25 PM, John Warburton < > jwarburton@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?) - 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. - 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 - To replace almost all case statements - 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. 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. 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. 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? How sharable is this set of layered classes with other teams, other business or event entirely unrelated 3rd parties via the forge? How many inheritance related bugs have gone reported but never fixed? 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? 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar <rip@devco.net> wrote:> 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? > >I''ll answer this one. The obvious, and correct, answer is, "because it''s a lot of work to do this." For Puppetlabs to do this, they''re going to have to invest a lot of time and energy, because their implementation *must* be backwards-compatible or else provide an automated tool for doing the conversion. Further, the PDL proposal hasn''t actually been around all that long. Puppetlabs isn''t Microsoft and doesn''t have a thousand developers on hand to write stuff up. Their staff is small and no matter how talented they are, there is limited time with each day. Even a user-contributed patch set probably will take time to vet simply because of the compatibility requirements. Caveat: I don''t work with or for Puppetlabs, and while I may occasionally complain about X or Y, I respect the work they are doing and their efforts to provide a quality product. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- Original Message -----> On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar < rip@devco.net > > wrote: > > > > 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? > > > > > I''ll answer this one. The obvious, and correct, answer is, "because > it''s a lot of work to do this." > > For Puppetlabs to do this, they''re going to have to invest a lot of > time and energy, because their implementation *must* be > backwards-compatible or else provide an automated tool for doing the > conversion. Further, the PDL proposal hasn''t actually been around > all that long. Puppetlabs isn''t Microsoft and doesn''t have a > thousand developers on hand to write stuff up. Their staff is small > and no matter how talented they are, there is limited time with each > day. Even a user-contributed patch set probably will take time to > vet simply because of the compatibility requirements.I get that, I wasnt intending to say ''why has it not been coded yet'' but more wondering why extlookup is being downplayed in the absence of a solution that solves the same problem as effectively. Many big users out there today says they cant live without extlookup, simply because it''s effective at solving the problem. So I think the original question is very valid - why tell people not to use a feature that is available in the core language? if it sux, remove it. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 04/12/2011 04:41 PM, R.I.Pienaar wrote:> > > ----- Original Message ----- >> On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar < rip@devco.net > >> wrote: >> >> >> >> 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? >> >> >> >> >> I''ll answer this one. The obvious, and correct, answer is, "because >> it''s a lot of work to do this." >> >> For Puppetlabs to do this, they''re going to have to invest a lot of >> time and energy, because their implementation *must* be >> backwards-compatible or else provide an automated tool for doing the >> conversion. Further, the PDL proposal hasn''t actually been around >> all that long. Puppetlabs isn''t Microsoft and doesn''t have a >> thousand developers on hand to write stuff up. Their staff is small >> and no matter how talented they are, there is limited time with each >> day. Even a user-contributed patch set probably will take time to >> vet simply because of the compatibility requirements. > > I get that, I wasnt intending to say ''why has it not been coded yet'' but > more wondering why extlookup is being downplayed in the absence of a > solution that solves the same problem as effectively. Many big users > out there today says they cant live without extlookup, simply because > it''s effective at solving the problem. > > So I think the original question is very valid - why tell people not > to use a feature that is available in the core language? if it sux, > remove it.Hi, I can see how this is a soft spot for you, but it wasn''t suggested that extlookup was doing a poor job. We''re talking the *Style* guide here. So extlookup is being effectively deprecated. You consented that PDL was going to be the superior solution. extlookup may even be going to be obsoleted (it definitely isn''t yet). While I believe that it''s a bit early to deprecate features when their successor is not even beta yet, I don''t see a big issue with it, either. After all, ENC+param classes are available if clumsy (as you put it). Cheers, Felix -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- Original Message -----> On 04/12/2011 04:41 PM, R.I.Pienaar wrote: > > > > > > ----- Original Message ----- > >> On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar < rip@devco.net > > >> wrote: > >> > >> > >> > >> 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? > >> > >> > >> > >> > >> I''ll answer this one. The obvious, and correct, answer is, > >> "because > >> it''s a lot of work to do this." > >> > >> For Puppetlabs to do this, they''re going to have to invest a lot > >> of > >> time and energy, because their implementation *must* be > >> backwards-compatible or else provide an automated tool for doing > >> the > >> conversion. Further, the PDL proposal hasn''t actually been around > >> all that long. Puppetlabs isn''t Microsoft and doesn''t have a > >> thousand developers on hand to write stuff up. Their staff is > >> small > >> and no matter how talented they are, there is limited time with > >> each > >> day. Even a user-contributed patch set probably will take time to > >> vet simply because of the compatibility requirements. > > > > I get that, I wasnt intending to say ''why has it not been coded > > yet'' but > > more wondering why extlookup is being downplayed in the absence of > > a > > solution that solves the same problem as effectively. Many big > > users > > out there today says they cant live without extlookup, simply > > because > > it''s effective at solving the problem. > > > > So I think the original question is very valid - why tell people > > not > > to use a feature that is available in the core language? if it sux, > > remove it. > > Hi, > > I can see how this is a soft spot for you, but it wasn''t suggested > that extlookup was doing a poor job. We''re talking the *Style* guide here.I think you miss understand me, I dont care for extlookup one way or the other, I''ve never really run the one in the core distro as I have some other enhancements that isn''t in Puppet. I do care what recommendations are made to the community - not just those who pay for training so they can understand complex data modeling with OO like inheritance. I care for a simple to understand, simple to explain CM language, one suitable for traditional systems adminis - the kind of guys I care for and who I want to help - and I think we''re failing them with ever more complex recommendations.> After all, ENC+param classes are available if clumsy (as you put it).Rather than use a feature that exist and solve the problem, the recommendation is that each user should *write their own ENC that models their data* and this is somehow more effective than just using the existing extlookup while the PDL is being developed? -- R.I.Pienaar -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 12, 12:45 am, Dan Bode <d...@puppetlabs.com> wrote:> 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. > > given the option between parameterized class combined with an ENC vs. > extlookup, I choose parameterized classes+ENC. The reason is readability and > encapsulation.I seem to be the person here to most vocally express reservations about parameterized classes in general, but am I really the only one who isn''t buying in? I do understand that Puppet Labs put considerable effort into developing the feature, and that they now tout it as one of the key improvements in 2.6, and that it furthermore serves as the foundation for run stages. But none of that makes it technically superior in its current form. Among parameterized classes'' problems are 1) parameterized classes can be included only once, unlike unparameterized ones. This tends to require modules to have an hierarchical structure, which isn''t very suitable in many circumstances. (More on that below.) It does, however, sort of address 2) parameterized classes present the opportunity to include the same class with different parameters in different places. It''s quite reasonable that doing so constitutes an error, but it is unfortunate that the DSL provides the opportunity to commit such an error in the first place. On the other hand, 3) parameterized classes not only permit, but tend to require this:> With param classes, you can build a layered architecture of classes that > pass data to each other through their explicit interfaces.Talk about losing encapsulation! Every parameter a class exposes constitutes a reduction in the encapsulation it provides. That''s even more the case when classes expose parameters solely to pass them on to other classes they include. That sort of parameter forwarding is likely to become necessary because the only sane way to manage an architecture wherein parameterized classes include other parameterized classes is to structure it hierarchically. A hierarchical manifest architecture isn''t particularly suitable, however, because real system configurations aren''t hierarchical. The Style Guide seems to poo-poo that last problem when it says "classes which require other classes should not directly declare them and should instead allow the system to fail if they are not declared by some other means." (Or at least I think that''s what it''s doing -- I find the Guide''s usage of the term "declare" to be a bit ambiguous.) Really, the Guide''s recommendation here is a practical necessity, not a stylistic issue, once you''re committed to a hierarchy of parameterized classes. But why is it presented as if it were a good approach? It creates points of failure that shouldn''t be needed, and it constitutes another encapsulation violation wherever it applies. Furthermore, 4) parameterized classes make configurations harder to maintain because changes to a class''s parameterization require corresponding changes wherever that class is included. This is a symptom of the loss of encapsulation inherent in parameterization (3, above), but I call it out specifically because it''s more concrete. Additionally, 5) parameterized classes, and especially the term "parameter passing" have a bit of code smell in declarative Puppet DSL. I''m satisfied that the implementation is appropriately declarative, but the concept evidently influences people toward thinking along imperative lines, which typically doesn''t fit well with Puppet, and which is already a big enough trap for the unwary. As I understand it, the main objectives of parameterized classes are (a) to provide an alternative to dynamically-scoped variables for influencing classes, and (b) to better document classes'' data dependencies. Indeed, the feature does achieve those objectives. I tend to discount the documentation aspect, however, for I don''t find class parameters adequate without ordinary text documentation, whereas text documentation can be adequate without parameterization. As for feeding data to classes, parameters certainly aren''t the only way, and with all their disadvantages, they usually aren''t the best way. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 12, 2011, at 8:03 AM, jcbollinger wrote:> 1) parameterized classes can be included only once, unlike > unparameterized ones. This tends to require modules to have an > hierarchical structure, which isn''t very suitable in many > circumstances. (More on that below.) It does, however, sort of > addressMy understanding is that there''s no difference between "parameterized classes you can include more than once" and defines. If you disagree, please enlighten me. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi all, Thanks for the input On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar <rip@devco.net> wrote:> > > ----- Original Message ----- > > > > > > > > On Mon, Apr 11, 2011 at 9:25 PM, John Warburton < > > jwarburton@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.> - 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 puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Apr 12, 2011 at 8:00 AM, R.I.Pienaar <rip@devco.net> wrote:> > > ----- Original Message ----- > > On 04/12/2011 04:41 PM, R.I.Pienaar wrote: > > > > > > > > > ----- Original Message ----- > > >> On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar < rip@devco.net > > > >> wrote: > > >> > > >> > > >> > > >> 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? > > >> > > >> > > >> > > >> > > >> I''ll answer this one. The obvious, and correct, answer is, > > >> "because > > >> it''s a lot of work to do this." > > >> > > >> For Puppetlabs to do this, they''re going to have to invest a lot > > >> of > > >> time and energy, because their implementation *must* be > > >> backwards-compatible or else provide an automated tool for doing > > >> the > > >> conversion. Further, the PDL proposal hasn''t actually been around > > >> all that long. Puppetlabs isn''t Microsoft and doesn''t have a > > >> thousand developers on hand to write stuff up. Their staff is > > >> small > > >> and no matter how talented they are, there is limited time with > > >> each > > >> day. Even a user-contributed patch set probably will take time to > > >> vet simply because of the compatibility requirements. > > > > > > I get that, I wasnt intending to say ''why has it not been coded > > > yet'' but > > > more wondering why extlookup is being downplayed in the absence of > > > a > > > solution that solves the same problem as effectively. Many big > > > users > > > out there today says they cant live without extlookup, simply > > > because > > > it''s effective at solving the problem. > > > > > > So I think the original question is very valid - why tell people > > > not > > > to use a feature that is available in the core language? if it sux, > > > remove it. > > > > Hi, > > > > I can see how this is a soft spot for you, but it wasn''t suggested > > that extlookup was doing a poor job. We''re talking the *Style* guide > here. > > I think you miss understand me, I dont care for extlookup one way or the > other, > I''ve never really run the one in the core distro as I have some other > enhancements that isn''t in Puppet. > > I do care what recommendations are made to the community - not just those > who pay for training so they can understand complex data modeling with > OO like inheritance. > > I care for a simple to understand, simple to explain CM language, one > suitable for traditional systems adminis - the kind of guys I care for > and who I want to help - and I think we''re failing them with ever more > complex recommendations. > > > After all, ENC+param classes are available if clumsy (as you put it). > > Rather than use a feature that exist and solve the problem, the > recommendation > is that each user should *write their own ENC that models their data* and > this is somehow more effective than just using the existing extlookup > while the PDL is being developed? > >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...> > -- > R.I.Pienaar > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- Original Message -----> Hi all, > > Thanks for the input > > > On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar < rip@devco.net > > wrote: > ----- Original Message ----- > > > > > > > > On Mon, Apr 11, 2011 at 9:25 PM, John Warburton < > > jwarburton@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 hereYou 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 futurecorrect, _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 questionhaving 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Apr 12, 2011 at 11:24 AM, R.I.Pienaar <rip@devco.net> wrote:> > > ----- Original Message ----- > > Hi all, > > > > Thanks for the input > > > > > > On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar < rip@devco.net > > > wrote: > > ----- Original Message ----- > > > > > > > > > > > > On Mon, Apr 11, 2011 at 9:25 PM, John Warburton < > > > jwarburton@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- Original Message -----> > > > On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar < rip@devco.net > > > wrote: > > ----- Original Message ----- > > > > > > > > > > > > On Mon, Apr 11, 2011 at 9:25 PM, John Warburton < > > > jwarburton@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.<lots snipped where you mostly agree with me that the style guide should be a roadmap doc> so whats the recommendation today for the user base then? -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 12, 10:49 am, Patrick <kc7...@gmail.com> wrote:> On Apr 12, 2011, at 8:03 AM, jcbollinger wrote: > > > 1) parameterized classes can be included only once, unlike > > unparameterized ones. This tends to require modules to have an > > hierarchical structure, which isn''t very suitable in many > > circumstances. (More on that below.) It does, however, sort of > > address > > My understanding is that there''s no difference between "parameterized classes you can include more than once" and defines. If you disagree, please enlighten me.Stand by for enlightenment. You can include unparameterized classes any number of times, and it means the same thing whether you include a class once or a hundred times. This is one of the fundamental characteristics of Puppet classes, and a feature that I personally put to good use. There is no reason in principle why you should not be able to include parameterized classes multiple times as well, provided that the parameters are everywhere the same for a given node. My expectation for such a case would be that the effect is the same as including the class only once, just as for unparameterized classes. Defines are altogether different: they are resource types written in Puppet DSL, much more akin to File or User than to any class. Whereas it must be an error to include a class two or more times with inconsistent parameter sets, multiple instantiations of a define *must* differ, at least in their titles. Whereas multiple inclusions of the same parameterized class (with consistent parameters) should mean the same as a single inclusion of that class, multiple instantiations of a define model separate resources to manage. Defines are nevertheless relevant to the discussion, because they can indeed serve in most of the roles for which parameterized classes are suggested. Since parameterized classes can only be included once anyway, the most significant distinction between a parameterized class and a define is largely mooted in practice. This then begs the question: for what purpose are parameterized classes uniquely useful? I may be missing something, but the only things I come up with are 1) Run stages. You cannot assign individual resources to stages, only classes, and you can only assign classes to stages via the parameter list syntax. That''s rather arbitrary, though, and I wonder whether you can get around it by using "before => Stage[''foo'']" on ordinary resources instead of "stage => foo" on classes. 2) External node classifiers. I think providing for ENCs to set class data is the main reason we now have parameterized classes. There is no particular reason, though, why parameterized classes needed to be provided to give ENCs such a capability. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 04/13/2011 12:34 AM, jcbollinger wrote:> You can include unparameterized classes any number of times, and it > means the same thing whether you include a class once or a hundred > times. This is one of the fundamental characteristics of Puppet > classes, and a feature that I personally put to good use. There is no > reason in principle why you should not be able to include > parameterized classes multiple times as well, provided that the > parameters are everywhere the same for a given node. My expectation > for such a case would be that the effect is the same as including the > class only once, just as for unparameterized classes.John, I used to think along the same lines. Not anymore. As a matter of fact, I don''t think non-parameterized classes should be considered equal to their parameterized counterparts. They are different concepts with different uses (which are unlike defines'', see below). It can be useful to be able to include things in multiple places and leverage the "singleton" qualities of non-parameterized classes. For the things you *do* parameterize, you will typically want to be sure it won''t get included anywhere far from node level. Being an 0.25 person, I have to rely on dynamic scoping here and there. The scoping problems are horrible, so most of the time I end up declaring variables near node level and immediately include the class that uses those variables. Parameterized classes allow for this to be written somewhat more explicitly, but I don''t expect them to become as flexible (wrt. distributed inclusion) as non-parameterized classes (anymore). Don''t even get me started on distributed inclusions of classes that do expect dynamically scoped variables.> Defines are altogether different: they are resource types written in > Puppet DSL, much more akin to File or User than to any class. Whereas > it must be an error to include a class two or more times with > inconsistent parameter sets, multiple instantiations of a define > *must* differ, at least in their titles. Whereas multiple inclusions > of the same parameterized class (with consistent parameters) should > mean the same as a single inclusion of that class, multiple > instantiations of a define model separate resources to manage.I *think* Patrick knew that ;)> Defines are nevertheless relevant to the discussion, because they can > indeed serve in most of the roles for which parameterized classes are > suggested. Since parameterized classes can only be included once > anyway, the most significant distinction between a parameterized class > and a define is largely mooted in practice. This then begs the > question: for what purpose are parameterized classes uniquely useful? > I may be missing something, but the only things I come up with areTechnically, you can replace each and every parameterized class with a define that bears a label "use this only once per node!" (which I''ve done in places with 0.25, as a matter of fact). Yes, it works. Yes, it has largely the same effect as a paramerized class. But that''s horrible design practice! Parameterized classes represent collections of unique resources. Drawing on the define paradigm to get something similar is ugly. I''ve talked a to Dan about this during the Berlin Meetup, and it was my impression that the vision is that future manifests should 1) declare most used classes near node level and 2) have interdepending classes produce failures when dependencies are missing (whereas in the 0.25 age, you would include dependencies and be done with it) This sounds very sane to me, but I haven''t had a change to really dabble in that type of design myself. For this discussion''s sake, I''d be honestly thankful to see some examples of classes that should both be parameterized and multiple-includable. (Yes, I am making up terms as I go ;-) Regards, Felix -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 04/12/2011 08:24 PM, R.I.Pienaar wrote:> 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.RI, I strongly disagree. When I ask Puppet Labs for help on good manifest writing practices, I would not want to be told what crude workarounds (no offense) are usable today. I want somewhat future-proof manifests (if at all possible). Background is that we are still investing a somewhat disproportionate amount of time into puppet development (when using puppet for managing customers'' systems). Nobody''s going to pay us for refactoring work. A style guide that recommends practices that are prone to need refactoring in a year or two would be a huge no. Sincerely, Felix -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 13, 2:42 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote:> On 04/13/2011 12:34 AM, jcbollinger wrote: > > > You can include unparameterized classes any number of times, and it > > means the same thing whether you include a class once or a hundred > > times. This is one of the fundamental characteristics of Puppet > > classes, and a feature that I personally put to good use. There is no > > reason in principle why you should not be able to include > > parameterized classes multiple times as well, provided that the > > parameters are everywhere the same for a given node. My expectation > > for such a case would be that the effect is the same as including the > > class only once, just as for unparameterized classes. > > John, > > I used to think along the same lines. Not anymore. As a matter of fact, > I don''t think non-parameterized classes should be considered equal to > their parameterized counterparts. They are different concepts with > different uses (which are unlike defines'', see below).Given my position that the good use cases for parameterized classes are specialized and few, I tend to agree about different uses. That parameterized and ordinary classes are different concepts appears to be more a de facto result than a design decision, however. Other aspects of Puppet tend to obscure such a distinction. Consider: * Puppet uses the same term ("class") and largely the same infrastructure for ordinary and parameterized classes. * The Language Guide explicitly comingles the concepts. It says "In Puppet 2.6.0 and later, classes are extended to allow the passing of parameters into classes." That''s a far cry from "a new kind of resource collection is available", or even from "some classes are special." * You can include an ordinary class via the parameterized-class mechanism (thereby causing Puppet to prevent its inclusion elsewhere), but you cannot include a parameterized class via ''include'', even if it has default values defined for all its parameters. * The only way to assign an ordinary class to a run stage is via the parameterized-class mechanism (which causes Puppet to treat it as a parameterized class). * Puppet Labs''s official Puppet Style Guide promotes parameterized classes and largely pushes ordinary ones under the rug. * Inasmuch as all classes have at least one *meta*-parameter (stage), Puppet blurs the line between ordinary and parameterized classes.> It can be useful to be able to include things in multiple places and > leverage the "singleton" qualities of non-parameterized classes. > For the things you *do* parameterize, you will typically want to be sure > it won''t get included anywhere far from node level.I agree, but the Style Guide doesn''t appear to do. It advises against using "include" at all, leaving only the parameterized class syntax for including classes (for which it uses the term "declare" instead of "include"). Following that advice effectively makes *all* classes be treated as if they were parameterized. In that context it makes sense that the Guide recommends that *all* classes be "declared" as close to node scope as possible, and that classes actively avoid including (declaring) other classes, but that doesn''t make those recommendations -- especially the second -- good in their own right.> Being an 0.25 person, I have to rely on dynamic scoping here and there. > The scoping problems are horrible, so most of the time I end up > declaring variables near node level and immediately include the class > that uses those variables. > Parameterized classes allow for this to be written somewhat more > explicitly, but I don''t expect them to become as flexible (wrt. > distributed inclusion) as non-parameterized classes (anymore).The more I consider the problem, the more I think parameterized classes are the wrong solution. They address the problem of providing data to classes by creating a new type of object to which you can explicitly provide data (if we distinguish between ordinary and parameterized classes), or by putting substantial restrictions on the usage of classes to which you can provide data (if we don''t distinguish). That''s not a good solution either way. Extlookup() is a better solution in several ways, but especially because it is applicable to any class, and because it doesn''t inherently impose limitations on the classes that use it. It''s in the Puppet 2.6 core, so anyone who can use parameterized classes can also use extlookup(). I haven''t studied the PDL proposal carefully; perhaps it would be an even better solution, but I have reservations about it because it is based on parameterized classes.> Technically, you can replace each and every parameterized class with a > define that bears a label "use this only once per node!" (which I''ve > done in places with 0.25, as a matter of fact). Yes, it works. Yes, it > has largely the same effect as a paramerized class. > > But that''s horrible design practice! Parameterized classes represent > collections of unique resources. Drawing on the define paradigm to get > something similar is ugly.I''d go with "inelegant", but "horrible" and "ugly" are too strong. I would have preferred for Puppet to use the existing inelegant solution, however, instead of introducing a new inelegant solution. Perhaps parameterized classes'' inadequacies can be addressed in some future version. I think it''s particularly inelegant that the Puppet 2.6 DSL blurs the distinctions between classes and resources. Not only is the usage syntax virtually identical, but even the language with which their use is described ("declare") is now the same. I swear I somewhere saw the phrase "declaring class resources" used in the sense of including classes (as opposed to declaring resources in their bodies), but I can''t find it now.> I''ve talked a to Dan about this during the Berlin Meetup, and it was my > impression that the vision is that future manifests should > 1) declare most used classes near node level and > 2) have interdepending classes produce failures when dependencies are > missing (whereas in the 0.25 age, you would include dependencies and be > done with it)Yes, this is largely what the Style Guide says. I object particularly to (2); see my previous comments on that topic in this thread, or alternatively, tell me what makes it a good idea (other than the limitations of the current implementation of parameterized classes).> This sounds very sane to me, but I haven''t had a change to really dabble > in that type of design myself. For this discussion''s sake, I''d be > honestly thankful to see some examples of classes that should both be > parameterized and multiple-includable. (Yes, I am making up terms as I > go ;-)That''s a hard request for me to fulfill, because I have trouble coming up with examples of classes that should be parameterized. On the other hand, as a matter of principle I think *all* classes should be multiple-includable. Only implementation details argue against it in practice. I think often what you might like to do is declare a class''s parameters once, and elsewhere allow other classes to include that class without redeclaring the parameters. For instance, perhaps you have a user::virtual class that on some nodes declares virtual LDAP users, but on other nodes delares the same virtual users as local. Such a class might provide a parameter by which the User provider can be specified. Other classes that want to realize users should include user::virtual, but they don''t care which User provider is in play. Now that I came up with that example, I realize that it points to an improvement that might be doable right away: allow the include statement to be used with parameterized classes. That could be achieved by slightly (but backwards-compatibly) changing the semantics of "include": 1) The "include" statement expresses a requirement that the specified class be included in the resulting catalog, but it says nothing about the class''s parameters. 2) If a class is named in at least one "include" statement that is executed while compiling a catalog, then the effect depends on whether the named class is "declared" elsewhere in the manifest: 2a) If the class is declared, then include statements referencing it have no additional effect. 2b) If the class is not declared, then it is treated as if the class were declared, without any explicit parameters, at the point where the first include statement appears. (Fixing the class declaration to the first include statement is intended to provide backwards compatibility.) If such a class declares a parameter for which it does not define a default value, then an error results. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 13, 3:17 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote:> On 04/12/2011 08:24 PM, R.I.Pienaar wrote: > > > 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. > > RI, > > I strongly disagree. When I ask Puppet Labs for help on good manifest > writing practices, I would not want to be told what crude workarounds > (no offense) are usable today. I want somewhat future-proof manifests > (if at all possible).I am not persuaded that the current style guide achieves that result, nor that extlookup() constitutes a workaround, crude or otherwise. Indeed, I have grave concerns about the maintainability of manifests that make heavy use of parameterized classes (including otherwise ordinary classes "declared" via parameterized-class syntax). With extlookup() in the core in 2.6, I see no reason to think it any less future-proof than the new, raw implementation of parameterized classes.> Background is that we are still investing a somewhat disproportionate > amount of time into puppet development (when using puppet for managing > customers'' systems). Nobody''s going to pay us for refactoring work. A > style guide that recommends practices that are prone to need refactoring > in a year or two would be a huge no.I would account a desire to avoiding future refactoring as an excellent reason to avoid parameterized classes, at least for now. I like many of the recommendations in the new style guide, but not so much the ones related to using parameterized classes (and effectively making all classes parameterized). Were I you, I would look hard at the idea that it is better to allow manifest compilation to fail than to explicitly include needed classes: following that advice makes manifests substantially less resilient and thus harder to maintain. I would also consider the added work that will be involved if ever a need to change a class''s parameterization arises. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> > > Background is that we are still investing a somewhat > > disproportionate amount of time into puppet development (when using puppet for > > managing customers'' systems). Nobody''s going to pay us for refactoring work. > > A style guide that recommends practices that are prone to need > > refactoring in a year or two would be a huge no. > > > I would account a desire to avoiding future refactoring as an > excellent reason to avoid parameterized classes, at least for now. I > like many of the recommendations in the new style guide, but not so > much the ones related to using parameterized classes (and effectively > making all classes parameterized). > > Were I you, I would look hard at the idea that it is better to allow > manifest compilation to fail than to explicitly include needed > classes: following that advice makes manifests substantially less > resilient and thus harder to maintain. I would also consider the > added work that will be involved if ever a need to change a class''s > parameterization arises.The param node classes basically insist that class declaration happens as close to the node scope as possible. Soon puppet will start warning if you use dynamic scoping and after that dynamic scoping will stop working this means ''include'' as we know it will stop working and might as well be removed from the language. This means every "node" block is now heavy with lots of parameters and because you have to declare the classes there you should also declare dependencies at that level for it to be clear. It also means each node block is full of data - the parameters - and the data is duplicated between nodes So in order to get DRY node blocks where adding a new node isnt a nightmare or where changing a property on 10s or 100s of nodes isnt a problem I see users using extlookup to lookup data that they then pass into param class declarations due to the lack of PDL. The solution being proposed is so dissfunctional that users are forced to combine the new functionality with that ''hack'' you are replacing just to get work done. This discourages code separation into multiple classes - think a class for the package, service and config each. Instead promotes big classes that does lots of tings because writing multi class modules has become MUCH more complex since declaring those classes now requires node data passed between them. The answer here to prevent this duplication and complexity is use an ENC, if you use an ENC to declare your classes the duplication happens outside of Puppet in a place people dont feel the pain. This leads us down a road where an ENC is now a dependency, to use Puppet you need and ENC because Puppet Labs is making language decisions that make any other use impossible or untenable. This is a huge concern, how long till the only way to get complex modeled data support into Puppet do you have only 2 options, code in another language yourself or pay for a commercial ENC? By pushing more and more and more into ENC''s aren''t we admitting that we''ve given up the struggle with the Puppet DSL? Aren''t we just saying we cant solve these problems with Puppet and its declarative language therefore we go out to a full language like Ruby where we can query databases to access paramters of nodes and other nodes because Puppet doesnt provide a DSL level search functionality? Where we can use full procedural loop constructs to declare classes, where we are creating resources based on hashes passed in from an entirely different language. You might as well just not use Puppet once you''ve reached this level of complexity in your ENC. -- R.I.Pienaar -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 12, 2:13 pm, Dan Bode <d...@puppetlabs.com> wrote:> I completely agree that this recommendation is a little lacking without an > existing ENC to back it up.It is lacking to the extent that it depends on an ENC at all, even if PL provided an outstanding one. Allowing an ENC to specify data is good. Requiring an ENC to be used is bad. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Apr 13, 2011 at 9:40 AM, R.I.Pienaar <rip@devco.net> wrote:> Soon puppet will start warning > if you use dynamic scoping and after that dynamic scoping will stop working > this means ''include'' as we know it will stop working and might as well > be removed from the language.Just to address this point... we are throwing deprecation warnings for dynamic scoping in Statler, e.g. this manifest: $foo = ''foo_value'' class a { $bar = ''bar_value'' include b } class b inherits c { notify { $baz: } # should not generate a warning -- inherited from class c notify { $bar: } # should generate a warning -- uses dynamic scoping notify { $foo: } # should not generate a warning -- comes from top scope } class c { $baz = ''baz_value'' } include a will throw a warning for $bar unless you refer to it as $a::bar. I''m not seeing the logical jump from there to "include as we know it will stop working" though RI? Can you elaborate? I believe we achieved consensus here on the list quite a while ago that it was desirable to move towards lexical scoping. We do have work to do to rehabilitate include vs param class declaration, and more feedback on http://projects.puppetlabs.com/issues/5046 would be great. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi John, On 04/13/2011 05:47 PM, jcbollinger wrote:> Given my position that the good use cases for parameterized classes > are specialized and few, I tend to agree about different uses. That > parameterized and ordinary classes are different concepts appears to > be more a de facto result than a design decision, however. Other > aspects of Puppet tend to obscure such a distinction. Consider: >< snip > You raise very good points that I won''t argue about.> I think often what you might like to do is declare a class''s > parameters once, and elsewhere allow other classes to include that > class without redeclaring the parameters. For instance, perhaps you > have a user::virtual class that on some nodes declares virtual LDAP > users, but on other nodes delares the same virtual users as local. > Such a class might provide a parameter by which the User provider can > be specified. Other classes that want to realize users should include > user::virtual, but they don''t care which User provider is in play.You get something similar by having some resources in each type of node require (by metaparameter, not by function) the class in question. No, it won''t get auto-included with default parameter values, but you do get a meaningful error message.> Now that I came up with that example, I realize that it points to an > improvement that might be doable right away: allow the include > statement to be used with parameterized classes. That could be > achieved by slightly (but backwards-compatibly) changing the semantics > of "include": > > 1) The "include" statement expresses a requirement that the specified > class be included in the resulting catalog, but it says nothing about > the class''s parameters. > > 2) If a class is named in at least one "include" statement that is > executed while compiling a catalog, then the effect depends on whether > the named class is "declared" elsewhere in the manifest: > > 2a) If the class is declared, then include statements referencing it > have no additional effect. > > 2b) If the class is not declared, then it is treated as if the class > were declared, without any explicit parameters, at the point where the > first include statement appears. (Fixing the class declaration to the > first include statement is intended to provide backwards > compatibility.) If such a class declares a parameter for which it > does not define a default value, then an error results.+1 ! Thanks for laying out your position so carefully. Speaking for myself, I learned quite a bit from your posting. Nigel: It would be nice to get "the developers''" position on these proposals. Cheers, Felix -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 14, 2:24 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote:> Hi John, > > On 04/13/2011 05:47 PM, jcbollinger wrote:[...]> > For instance, perhaps you > > have a user::virtual class that on some nodes declares virtual LDAP > > users, but on other nodes delares the same virtual users as local. > > Such a class might provide a parameter by which the User provider can > > be specified. Other classes that want to realize users should include > > user::virtual, but they don''t care which User provider is in play. > > You get something similar by having some resources in each type of node > require (by metaparameter, not by function) the class in question. > No, it won''t get auto-included with default parameter values, but you do > get a meaningful error message.Yes, but what I would actually do right now is use extlookup(). It solves the problem cleanly, and the resulting manifests just work. It looks like the problem could as easily be solved with PDL, or with a mechansim for allowing multiple inclusion of parameterized classes. But addressing it via today''s version of parameterized classes opens you up to needless errors and therefore makes your manifests harder to maintain. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Apr 14, 2011 at 12:24 AM, Felix Frank < felix.frank@alumni.tu-berlin.de> wrote:> Hi John, > > On 04/13/2011 05:47 PM, jcbollinger wrote: > > Given my position that the good use cases for parameterized classes > > are specialized and few, I tend to agree about different uses. That > > parameterized and ordinary classes are different concepts appears to > > be more a de facto result than a design decision, however. Other > > aspects of Puppet tend to obscure such a distinction. Consider: > > > < snip > > > You raise very good points that I won''t argue about. > > > I think often what you might like to do is declare a class''s > > parameters once, and elsewhere allow other classes to include that > > class without redeclaring the parameters. For instance, perhaps you > > have a user::virtual class that on some nodes declares virtual LDAP > > users, but on other nodes delares the same virtual users as local. > > Such a class might provide a parameter by which the User provider can > > be specified. Other classes that want to realize users should include > > user::virtual, but they don''t care which User provider is in play. > > You get something similar by having some resources in each type of node > require (by metaparameter, not by function) the class in question. > No, it won''t get auto-included with default parameter values, but you do > get a meaningful error message. > > > Now that I came up with that example, I realize that it points to an > > improvement that might be doable right away: allow the include > > statement to be used with parameterized classes. That could be > > achieved by slightly (but backwards-compatibly) changing the semantics > > of "include": > > > > 1) The "include" statement expresses a requirement that the specified > > class be included in the resulting catalog, but it says nothing about > > the class''s parameters. > > > > 2) If a class is named in at least one "include" statement that is > > executed while compiling a catalog, then the effect depends on whether > > the named class is "declared" elsewhere in the manifest: > > > > 2a) If the class is declared, then include statements referencing it > > have no additional effect. > > > > 2b) If the class is not declared, then it is treated as if the class > > were declared, without any explicit parameters, at the point where the > > first include statement appears. (Fixing the class declaration to the > > first include statement is intended to provide backwards > > compatibility.) If such a class declares a parameter for which it > > does not define a default value, then an error results. >+1> +1 ! > > Thanks for laying out your position so carefully. Speaking for myself, I > learned quite a bit from your posting. > > Nigel: It would be nice to get "the developers''" position on these > proposals. >We started having this conversation back in October, but no design decision was ever made. Here are some links to tickets related to how include and param classes working together: http://projects.puppetlabs.com/issues/5046 Perhaps with the pending changes to dynamic scoping its worth revisiting this ticket and seeing how include and param classes can work together. http://projects.puppetlabs.com/issues/5089 http://projects.puppetlabs.com/issues/5074> Cheers, > Felix > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
jcbollinger:> 1) The "include" statement expresses a requirement that the specified > class be included in the resulting catalog, but it says nothing about > the class''s parameters. > > 2) If a class is named in at least one "include" statement that is > executed while compiling a catalog, then the effect depends on whether > the named class is "declared" elsewhere in the manifest: > > 2a) If the class is declared, then include statements referencing it > have no additional effect. > > 2b) If the class is not declared, then it is treated as if the class > were declared, without any explicit parameters, at the point where the > first include statement appears. (Fixing the class declaration to the > first include statement is intended to provide backwards > compatibility.) If such a class declares a parameter for which it > does not define a default value, then an error results.I agree with the chorus of +1s for this proposal, largely because I feel that this is how people intuitively *expect* this interaction to work right now. This is the least surprising outcome, in general. I just hope it doesn''t require too many extra passes over the AST to ensure declaration status! -- "As I soared high into the tag cloud Xeni Jardin carefully put up for me, I couldn''t help but wonder how high we were above the blogosphere." -- Carlos Laviola -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.