Hi Florian On Tue, 4 Nov 2008 04:04:01 -0800 (PST) jerico <[EMAIL PROTECTED]> wrote:
> > Hi Lorenz, > > > I've commented on that before but i might revise my statement. I use > > classes almost exclusively for grouping together defines and > > therefore i'm not very concerned about class-level parameters. > > As you I am using classes nearly exclusively to bundle definitions. I > currently impose a very strict installation hierarchy "by convention" > anyway. So "above"/"below" comes naturally to me. > > Therefore I like your idea of "above" and "below" as it solves some of > my problems as well although I unfortunately do not find the time to > fix the code as you did. Thanks for your contribution! I'll try it out > later. Unfortunately the plugin-approach does only work if puppet runs in standalone mode because only the server knows about function plugins. perhaps its possible to trick puppetd into loading the code if it is provided as a type/provider plugin instead of a function plugin. It is still possible to patch puppet (>0.24.5) to get above/below working in client/server mode using the following patch: <http://znerol.ch/files/0001-above-and-below-vertical-dependency-metaparameters.patch> My biggest problem now is that i have to eliminate virtually every autorequire by explicitly specifying above/below because otherwise its likely that the dependency tree gets messed up when resources are deleted. > My current workaround is: I am using a custom "installed" parameter > with my definitions to emulate the behaviour you are providing through > "above"/"below". Then I use a couple of "if" statements within my > definitions that ensure that enable, ensure, require, before, notify > and subscribe get fixed depending on installed=false or > installed=true. Like that I can uninstall resources as a bundle and in > the right order without causing damage. I leave them in "uninstalled" > state until all nodes have updated their state then I can remove the > definition instances from the configuration. > > I prefer this approach over class inheritance (enable/disable): > [...] > It's obvious that I'd prefer a "native" solution to the problem rather > than having to work around it with all the practical problems implied. For sure, me too. > [...] > > See this post for a rather complete discussion of the conceptual > similarities/differences between classes and defines (and scope for > improvement) that I had with Luke: > > [...] I'm following that thread with great interest. Lorenz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
