hello, ----- "Peter Meier" <[email protected]> wrote:
> >> > 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. > >> > >> if you use only autoloading and inheritance you don't need to use > >> import at all to achieve your goal. At least I think this is what > I'm > >> doing to solve this kind of problem and it works pretty well. I > don't > >> yet see why you would need any kind of mixins. If you still think > you > >> need it, could somebody explain why you would need that instead of > >> inheritance and inclusion? > > > > You should read my earlier mail that explains the use case. > > > > http://groups.google.com/group/puppet-dev/msg/db8e93c12207f79d > > ah right. Currently I would do this kind of things one one side with > inheritance (if I want to access variables from openvpn::config) and > with inclusion if I want to set certain variables first: My example, the original poster, the ticket and Nigel (I think) pointed out that the approach below wreaks havok with dependencies and requires and you end up basically having a weird dangling class that does not form part of the original intended ordering and dependencies of the module. For example, you would want to let openvpn::service depend on myopenvpn::config below, how would you do this without editing openvpn::service? And what if openvn::service come from a module repository that gets updated at times? > class openvpn { include openvpn::config } > > class openvpn::config { > $somebar = 'helo' > file{'some_file': content => "helo" } > } > > > class myopenvpn inherits openvpn{ > $foobar = root > include myopenvpn::config > } > > class myopenvpn::config inherits openvpn::config { > File['some_file']{ owner => $foobar } > notice("$somebar") > } This would essentially be a run-many-times-till-it-works approach rather than a clean dependency based solution, unless you put in a lot of before => properties in these classes, and this too would not really do it properly. > > I'm not (yet ;) ) really arguing against your proposed solution, I'm > > just trying to understand the problem you'd like to have solved. resources in openvpn::service requires Class["openvpn::config"] and this cleanly ensures all config happens before the service happens, I think is essential in achieving the goal of sharing modules that are not just configurable but also extendable to local needs -- 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 -~----------~----~----~----~------~----~------~--~---
