----- "Luke Kanies" <[email protected]> wrote:
> On Oct 15, 2009, at 12:32 AM, R.I.Pienaar wrote: > > > > > 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. > > This doesn't seem any different than what I thought we were already > talking about: > > class openvpn { ... } > > class client1::openvpn extends openvpn { ... } > class client2::openvpn extends openvpn { ... } > > node default { > include "$hostname::openvpn" > } > > Or am I missing something? Well if we're just using import for this once something has been imported it would be visible to the whole manifest, so if client1 extends ::config then client2 would get those extensions too, afaik, again I'm not a big user of import but this seems right with what i remember so worth clarifying. > > > 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 > > Can you open feature requests documenting the behaviour you're looking > for? will do over the weekend -- 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 -~----------~----~----~----~------~----~------~--~---
