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
-~----------~----~----~----~------~----~------~--~---

Reply via email to