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? -- Do you realize if it weren't for Edison we'd be watching TV by candlelight? -- Al Boliska --------------------------------------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
