extlookup == bad?
John Warburton
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
Dan Bode
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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
R.I.Pienaar
----- Original Message -----
>
>
>
> On Mon, Apr 11, 2011 at 9:25 PM, John Warburton <
> jwarb...@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.
Brian Gallew
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.
R.I.Pienaar
----- Original Message -----
> On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar < r...@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.
Felix Frank
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
R.I.Pienaar
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
jcbollinger
On Apr 12, 12:45 am, Dan Bode <d...@puppetlabs.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.
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.
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
Patrick
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.
Dan Bode
Thanks for the input
This is not what extlookup is for. Yes it effectively works around the
----- Original Message -----
>
>
>
> On Mon, Apr 11, 2011 at 9:25 PM, John Warburton <
> jwarb...@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.
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.
How easy is it to adjust how you layer these classes?
>
> 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.
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.
Dan Bode
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
R.I.Pienaar
Solving this problem with an ENC is suitable for people who can program.
You are saying 'puppet cannot do this on its own, please write a whole
bunch of code in $language to address the shortcoming' is this the
message to send people who do not want to pay someone to come write
that ENC?
In the context of the question: do we use extlookup to solve this problem
or do we use an ENC to solve the problem.
Your answer here is extlookup isnt needed, just write your own ENC. I am
saying this is a very un newbie friendly message to send to the user base
when there is a way to solve the problem now while puppetlabs works on
either a good ENC that we can download or work on finishing the PDL.
> - it is easy to grasp, easy to train members of a team and with a bit
> of discipline its trivial to look at a class and know how you can
> configure it.
>
>
> The fact that you have to look at the class to understand what data
> it accepts is my main complaint.
today, the day your recommendations are up there for everyone to adhere
to and the scope of the question from the OP, this is no different
with parametrized classes. There is no released introspection tool,
there is no ability in dashboard to just ask the information it needs,
to use a paramterized module, u need to open its classes and look at its
params. Is this not the case?
You seem to say here's a set of recommendations for how to use puppet,
we think this is how you should do it and our reasons for saying so is
that there's a bunch of unreleased features that makes it awesome.
> I have not found parameterized classes problematic to teach, do you
> have some specific experiences around this?
No hard evidence, gut feel is if you go ask in #puppet or get together
a representative group of people who have not been trained by PL you
will probably find param classes are in very minimal use because they
are a solution looking for a problem today - because the full picture
isnt clear without PDL and so forth
>
>
> - It doesnt require any code changes to change the way the data
> behaves
> which is great for shared code like those found on the forge. Unlike
> the layered class approach
>
>
> I am not sue what you mean here
You can just configure your data source to behave in line with local
policies - not change the code. Which means if you cloned code from
elsewhere the fork is a clean clone rather than a fork.
Changing data vs rewriting code is very important from a change control
point of view etc
> The last point is the big one, Puppet has always been a language for
> sysadmins who want to automate their infrastructure. The layered
> class approach is something that you only get once sat in a class and
> taught. In this regard Puppet has lost its way.
>
>
> That is a really strong assertion RI. We are doing our best to create
> reasonable practices that 'we' can use to create modules, we have
> shared our first reasonable version of those with the community so
> that we can work to make it better.
the recurring recommendation is to use a ENC. There is no decent ready
to use ENC that people can just download - dashboard isnt great yet.
So in order to use Puppet today and get strong data modeling you have
to be a team who can *program* an ENC, the kind of team who can think
about abstract concepts like layered data and modeling of real world
objects into data. Turning this model into a full featured ENC that
integrates with a database is a skill that systems administrators lack.
ENCs are your hammer of choice to attack all problems because you are
a good programmer - or devops or whatever - we used to have a good
story for non devops people, today the recommendation is to just
write your own ENC
If all the user needs is to model data you are saying dont use extlookup
to solve this problem elegantly and out of the box without any further
development. Instead learn to program (or pay for support) and write
your own data model system. This is a huge barrier to entry.
also from your other mail:
> I agree with this. One huge problem with this recommendation is that
> we have still not shipped a feature complete ENC that can serve as a
> replacement to the data modeling that extlookup provides. This
> argument would be a lot more compeling if it was "use param classes,
> and Puppetlabs super cool ENC". I have spent some time working with
> customers to explain how to build these, and I have been working on
> one that supports the model that I have in mind...
This demonstrates the problem. You have had to spend time working
with customers to explain how to build these. It's a very complex
subject, something our target audience in many cases dont get. They
do understand extlookup though and it does solve a high % of their
problems *today*. So why make their life harder.
I too want to see a better ENC and PDL launched, I also want to see
param classes maturing into something truly usable. they are not
yet this though, so why recommend users shoot themselves in the foot
by not using the existing tools that is out there today to solve their
problems today.
You seem to skim over the bits of this mail about the PDL, would be
good to get your views on how the PDL relates or do you think it
shouldn't exit?
>
>
>
> It is not awesome though, there are limits to how you can configure
> the
> data the approach it takes isn't flexible enough really but it solves
> most of the problems it set out to solve. You cant programatically
> figure out what a class requires like you can with param classes if you dig
> deep enough.
>
> I hope we do a better job of exposing those APIs in the future
correct, _in the future_ its not there yet, to use param classes you need
to edit the file and look at it. Just like with extlookup. Where's the
win today?
> > In order to understand an implementation of Puppet using extlookup,
> > you have to understand all of your code in its entirety. After all,
> > any code anywhere in your modulepath could be calling extlookup and
> > accessing data. (I would be very interested to hear if anyone has a
> > good pattern for this)
> >
> > With param classes, you can build a layered architecture of classes
> > that pass data to each other through their explicit interfaces.
>
> How easy is it to adjust how you layer these classes?
>
> I do not understand this question
having first modeled my data into fqdn and DC specific, I now want to add
a new layer into my layered classes hierarchy to expose per country data
this is a trivial change in extlookup and PDL, its much harder with a
layered class approach
> How sharable is
> this set of layered classes with other teams, other business or event
> entirely unrelated 3rd parties via the forge?
>
> this is one of the main reasons that I like param classes, explicit
> interfaces should make sharing/collaboration easier.
*should* make it easier, but does it really? People need to study every
class and understand every parameter, and then declare all those parameters
and model the data today.
Why have we not seen a huge explosion of reusable modules on the forge
since 2.6 came out? Because without a data solution its not a solved
problem.
Tomorrow they might just use the PDL and all the pain will go away,
this is what is the ideal scenario, but I feel recommendations being made
to the community should reflect the present and evolve with the tool set
so the community can discover the improvements you make. Your style guide
is effectively a roadmap for how Puppet might one day work, not for how it
works well today.
Dan Bode
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 bittoday, the day your recommendations are up there for everyone to adhere
> 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.
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 youNo hard evidence, gut feel is if you go ask in #puppet or get together
> have some specific experiences around this?
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
You can just configure your data source to behave in line with local
>
>
> - 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
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 forthe recurring recommendation is to use a ENC. There is no decent ready
> 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.
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
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.
>correct, _in the future_ its not there yet, to use param classes you need
>
>
> 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
to edit the file and look at it. Just like with extlookup. Where's the
win today?
having first modeled my data into fqdn and DC specific, I now want to add
> > 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
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*should* make it easier, but does it really? People need to study every
> 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.
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.
--
R.I.Pienaar
<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?
jcbollinger
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
Felix Frank
> 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 are
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'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
Felix Frank
> 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
jcbollinger
On Apr 13, 2:42 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
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).
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.
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).
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.
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)
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 ;-)
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
jcbollinger
On Apr 13, 3:17 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
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).
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.
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
R.I.Pienaar
> > 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
jcbollinger
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.
PL provided an outstanding one. Allowing an ENC to specify data is
good. Requiring an ENC to be used is bad.
John
Nigel Kersten
> 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.
Felix Frank
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
jcbollinger
On Apr 14, 2:24 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
>
> 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.
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
Dan Bode
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
Nick Moffitt
> 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