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?
> 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?
--
You can't wait for inspiration. You have to go after it with a club.
-- Jack London
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
