On Oct 14, 2009, at 5:03 PM, R.I.Pienaar wrote: > > > ----- "Luke Kanies" <[email protected]> wrote: > >> On Oct 14, 2009, at 4:46 PM, R.I.Pienaar wrote: >> >>> >>> >>> ----- "R.I.Pienaar" <[email protected]> wrote: >>> >>>> ----- "Luke Kanies" <[email protected]> wrote: >>>> >>>>> On Oct 14, 2009, at 3:48 PM, R.I.Pienaar wrote: >>>>> >>>>>> >>>>>> hello, >>>>>> >>>>>> ----- "Luke Kanies" <[email protected]> wrote: >>>>>> >>>>>>> The solution Arri recommends is what I would also recommend - >>>>>>> something akin to his extlookup function, or the datalookup >>>>>>> function I >>>>>>> >>>>>> >>>>>> there are two domains of problem here. >>>>>> >>>>>> - Configuring the behavior of a module >>>>>> - Extending the behavior of an existing module. >>>>>> >>>>>> For the first, use extlookup without question. >>>>>> >>>>>> The second is more complex, here's a use case. >>>>>> >>>>>> I found a openvpn module on the net - perhaps from the puppet >>>> common >>>>> >>>>>> modules project - and its a good fit, its configurable using >>>>>> extlookup so i can adjust the outcome of the stuff it already >>>> knows >>>>> >>>>>> how to configure. >>>>>> >>>>>> Now I build 10 machines but I have new needs, I really need >>>>>> openvpn::config to do more, it needs to put new files down - >>>> perhaps >>>>> >>>>>> the existing module doesn't support per client configs (called >> ccd >>>> >>>>> >>>>>> in openvpn). >>>>>> >>>>>> now there might be a relationship between openvpn::install, >>>> ::config >>>>> >>>>>> and ::service and my new code really should *plug into* >> ::config. >>>>>> >>>>>> I really would want to put my new config files in >> openvpn::config >>>> >>>>>> without changing the relationships or the existing elegant and >>>>>> configurable structure. Perhaps the openvpn::config class >> already >>>> >>>>> >>>>>> retrieves some variables from extlookup and most certainly when >> I >>>> >>>>>> extend it I want access to this info. >>>>>> >>>>>> Today what are my options for possible patterns to achieve this? >>>> >>>>>> There's none that ticks all the boxes: >>>>>> >>>>>> - I can make myopenvpn and include ::service, ::config, >> ::install >>>> >>>>>> and just add some extra stuff in there myopenvpn perhaps with a >>>> few >>>>> >>>>>> before => Class["openvpn::service"]. This doesnt give me access >>>> to >>>>> >>>>>> the extlookup data in the class I'd need to go look and do the >>>> same >>>>> >>>>>> lookups, etc. It also does rather brutal things to the nice >>>>>> relationship models since other cases that require => >>>>>> Class["openvpn::config"] wont have requires on my new extra >>>> stuff. >>>>>> >>>>>> there are more, but you can see the kind of reservations I have >> to >>>> >>>>> >>>>>> them. >>>>>> >>>>>> How does ruby aproach this problem? Simple. >>>>>> >>>>>> class String >>>>>> def to_whatever >>>>>> # new code >>>>>> end >>>>>> end >>>>>> >>>>>> Now all my strings have this new ability, sweet and this doesnt >>>>>> break anything, no other classes or strings needs to change, >>>>>> everything can just use this new "foo".to_whatever method. >>>>>> >>>>>> What if I could do the same with puppet, open up the class >>>>>> openvpn::config, put new "stuff" into it? >>>>>> >>>>>> class openvpn::config { >>>>>> file{"newfile": >>>>>> content => template("newfile.erb") >>>>>> } >>>>>> } >>>>>> >>>>>> This template would have access to variables set in the super >>>> class >>>>> >>>>>> via extlookup I'd simply be extending it. >>>>>> >>>>>> How to trigger it on a node? >>>>>> >>>>>> node foo { >>>>>> load openvpn::extendedconfig >>>>>> >>>>>> include openvpn::config >>>>>> . >>>>>> . >>>>>> } >>>>>> >>>>>> now, openvpn::config would have both the content from common >>>> modules >>>>> >>>>>> and my newfile. >>>>>> >>>>>> Obviously perhaps my suggested syntax is cludgy, I'm more >>>> concerned >>>>> >>>>>> about the concept right now than the how. >>>>>> >>>>>> I think this captures more what the initial poster had in mind. >>>>> >>>>> One of the many undocumented "features" in Puppet: >>>>> >>>>> class foo { >>>>> notify { "foo": } >>>>> } >>>>> >>>>> class foo { >>>>> notify { "bar": } >>>>> } >>>>> >>>>> include foo >>>>> >>>>> Works fine. The only caveat is that if you evaluate 'foo' >> between >>>> the >>>>> >>>>> reopening, the added code won't get evaluated. >>>>> >>>>> Does this provide the behaviour you're asking for? Obviously >> there >>>> >>>>> are still limitations - your code has to be loaded manually, >> can't >>>> be >>>>> in a module with the same name, etc. >>>>> >>>> >>>> >>>> See http://pastie.org/655384 >>>> >>>> howly crap :) >>> >>> >>> OK, initial excitement over, this is awesome but relies on import >>> and import is not overly clever. >>> >>> We need something like import that understands modulepath and >>> environments, so that import("openvpn/extendedconfig.pp") does the >> >>> right thing - finds the right openvpn module as per modulepath for >> >>> this environment and then does a normal import. >>> >>> Since using modules I never import things it might be that I missed/ >> >>> forgot some crucial bit of trickery with import but I doubt it can >> >>> do this - dito for the file() function really >> >> >> Good point; import could be relatively easily extended to fix this. >> With that in place, how far would you be from where you think we need >> to be? > > > I'm feeling warm fuzzies but I need to play a bit, import is a bit > of a dirty little thing, something like: > > node foo { > openvpn::newstuff extends openvpn::config > > include openvpn::config > } > > end result would be that - there would be no openvpn::newstuff in > the classes list only openvpn::config. Effectively this is exactly > an import as discussed, just a different syntax, you'll go find the > file using the module search method and just import it.
I was thinking exactly this kind of syntax, and it'd be pretty easy to implement. > this would be more obvious about whats happening, what this file > does etc, the intend is clearer than with import. > > Ofcourse this means external nodes and so forth need the same ability, > > I think perhaps this extends style syntax might be 1.0 target while > a fixed up import might be 0.25.6? Give us some time to give this a > spin and work out what we're missing. Do you need the fixed-up import, at that point? And what specifically do you want done to it? -- Happiness is not achieved by the conscious pursuit of happiness; it is generally the by-product of other activities. -- Aldous Huxley --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
