On 5/14/2010 11:17 PM, R.I.Pienaar wrote:
hey,

----- "Luke Kanies"<[email protected]>  wrote:

Yep.

It's plenty dangerous.  In particular, it's probably pretty easy to
get cycles in your graph now.  E.g., say you do this:

Stage[pre] ->  Stage[main] # yay new syntax

class apt {
   file { "/some/apt/config": ensure =>  present }
   exec { "/usr/bin/apt-get update": require =>  File[/some/apt/config],
stage =>  pre }
}

Boom.  You've got a cycle.  The config file is still in 'main', the
exec is in 'pre', main depends on pre, and the exec depends on the
file.



since a specific stage isnt specified in the file, could the
dependency pull it into that stage?

You'd still have a deadlock situation when there are resources in
multiple stages depending on a resource - they cant pull it into both
stages - but this should be a situation you can detect and report with a
specific error message that makes it clear thats the situation rather
than the usual resource cycle spew?


I'd prefer prohibiting dependencies across stage-boundaries alltogether. It makes for a simple rule and pretty obvious error messages ("Exec[update] cannot require File[config] because they are on different stages: pre and main").

Pulling in the dependencies would make the concept pretty useless. Consider "require=>Class[class_with_many_packages]" instead of the File[] in the example.

This is one reason why I wanted to restrict the stages to just classes
- it would at least discourage this ability, if not outright prohibit
it.

If you want to restrict it, restrict it to dependencies within a stage.

But in the end, it's probably better to leave the sharp knives lying
around than to limit people here.

+1

--
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

       FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg

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

Reply via email to