Hell Again, Well, after reading a big part of the puppet source, the rspec tests and the wiki i'm still convinced that the puppet dependency handling can be enhanced by implementing my original proposal. I now found a way to provide this mechanism without altering the puppet core (at least not patching it). Instead i've put together a function plugin which injects the necessary code on demand. I've tested the code with puppet versions 0.24.5 and lukes branch from github.
It is now possible to test the feature by getting the following two files and play with them on a vanilla puppet installation. See the first one on how to install and use the plugin: http://znerol.ch/files/vertical_dependencies.rb http://znerol.ch/files/vertical-dependencies-test.pp Additional comments inline. On Fri, 24 Oct 2008 11:48:17 -0500 Luke Kanies <[EMAIL PROTECTED]> wrote: > [...] > I actually tried this maybe 1.5 years ago, and it was basically > completely untenable and pissed everyone off. Hm. Could you please be more specific on that? I was not able to find the code / comments in the git history. > The crux is: What happens if you need to delete a resource in order > to correctly configure another resource? That is, correct > configuration of a given resource class requires negation of some > resource. > > In that case, we would incorrectly set order, which would then break > everything. No, you just use "require" to depend on the other resource in exact the same order like you did before. "above" and "below" metaparameters do not alter the behavior of "require" and "before" in any way. > The only real way to do something like this is to have class-level > 'ensure'-equivalents: We'd need to be able to talk about the whole > service class being present or running or whatever, and then the > 'ensure' state of all contained resources would be bit-flipped > depending on what we did with that class-level state. 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. I somehow worked around them. On the other hand i see that there are some use cases for parametrized classes but i just would think about them as singleton defines - which is what they actually are in reality. 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 -~----------~----~----~----~------~----~------~--~---