hello, ----- "Luke Kanies" <[email protected]> wrote:
> 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? The new proposed syntax would be good enough but I think the improved import would be helpful anyway see below. The new syntax made me realize another requirement - not satisfied by import - the extensions has to be node/class specific. A common pattern is site modules or client modules that get used to apply specifics to a site based on your usual modules, sticking with openvpn: node ovpn1.CLIENT1.com { client1::openvpn::config extends openvpn::config include openvpn } ditto for client 2, in client1::openvpn::config I would enable a client to add ccd vpn records perhaps using a utility define offered by the main openvpn:: module, you'd still want them to happen as part of openvpn::config so this wold be great, but, client2 shouldn't get client1's extensions. So, new syntax to enable this, fixed up import just to make it more awesome than present, and perhaps as a means of global extends otherwise we could just make this new syntax work in site.pp if someone did want to extend openvpn::config globally -- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
