r...@devco.net ("R.I.Pienaar") writes:
> > Let me not be taken as an extlookup() zealot. I do like the design
> > as it is, but that doesn't mean it is ideal -- or even good -- for every
> > purpose. One of the advantages of Puppet, however, is that it is
> > fairly easy to modify and extend. If you would like an alternative
> > lookup facility then by all means, write one. If you are community-
> > minded then you could consider sharing it; the Puppet Forge (http://
> > forge.puppetlabs.com/) makes it easy to do that.
> >
> > You may also be interested in some of the extlookup() author's
> > comments about it (http://www.devco.net/archives/2009/08/31/
> > complex_data_and_puppet.php). He hangs out here, so you may also
> > hear from him directly.
> >
>
> So extlookup wasnt written as a be-all and end-all of data sources.
>
> I recognized we want data and code separation and of course I could write
> an ENC but I also recognized that I could do something generic that would
> solve a large % of cases for people to push out the point at which they
> need an ENC a bit later or in many cases entirely. I hoped I could solve
> it in a way that adds some value like make it easier to write configurable
> modules and to do so in a way that people without programming backgrounds
> can grasp and use and make their manifests a bit better.
>
> With this in mind I wrote extlookup aiming to solve the most common problems.
>
> I am not against ENCs I think big/complex shops absolutely must have them and
> I
> think a lot of the extlookup bashers missed this point - if you are big
> enough or complex enough where extlookup doesnt work for you then you've
> probably reached a legitimate point where investing time in writing an
> ENC is time well spent. And you're also not any more the the target audience
> extlookup was created for.
That's an interesting thought and also something I'm not sure of the answer to.
Personally I'm responsible for managing quite a few database servers, but the
company of course has several more severs of different types what we manage
besides that.
When I looked at the ENCs it seems to approach (if I understand how
they should be written) the problem from a different point of
view. That is provide: a list of global variables, and a list of
classes which should be defined for each node. That requires thinking
about the problem in quite a different way to the extlookup()
functionality which basically says: give me this value, and now based
on that I can decide what to do... That's my understanding of the view
"views" of how to configure a system. If that's right one thing I don't like
with the ENCs is the fact that it appears to use and rely on a large number
of global variables which are then used by the classes. As systems get more
complex that strikes me as not being good as the class behaviour may
change depending on the scope of where something comes from and how it's
included
and that's not clear. I've already been tripped up by not setting a global
variable
correctly (or using the wrong name) and not noticing and of course behaviour
changes. So I still think it's clearer if you can do:
$ip_address = extlookup( parameters to get an ip address )
$interface = extlookup( parameters to get an interface name )
interface::check{ $interface: ip_address => $ip_address }
than
inteface::check{ $global_interface1: ip_address => $global_ip_address1 }
as in the latter case it's not clear where these 2 values come
from. Their names are also less intuitive and if you have a number of
these to set then it gets worse.
> You should though just look at extlookups code, its extremely simple and easy
> to understand (especially since Jesse rewrote my ancient crappy code) and
> this
> should let you hack up solutions that solves your problems.
Ive tried to keep away from Ruby. Perhaps that's a real issue but yes, given
the idea is certainly sound, extending in a way that's more appropriate to my
perceived needs seems a sane approach.
> Puppet is a framework, its very hackable, its easy to write functions and
> types,
> easy to copy them out to all your servers and make it work in new and
> interesting
> ways. So I totally encourage you to use extlookup as a example and solve the
> problem in your own way or even to evaluate writing your own ENC.
One way or another I am probably going to go down that path. For the reasons
stated earlier building a complete ENC means that everything depends on it.
using a extlookup() type functionaliy initially at least makes the change seem
less imposing. However, if used heavily in the end it's doing just the same
thing,
but a different way.
Thanks for your comments.
Simon
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
