On Thu, 2010-03-18 at 20:22 -0400, Trevor Vaughan wrote:
> Would it be possible to detect a recursive file operation, stop at that
> point in the graph and then simply call the corresponding Ruby code the
> rest of the way down for specific operations?
> 
> I can, unfortunately, see this approach wreaking havok with my recent
> symbolic mode patch as an example of where it wouldn't work.
> 
> Alternatively, instead of merging all of the sub-file objects into the
> main graph, could you create a subgraph that is built off of a DFS from
> that originating recurse point?

I thought about this. It all depends on how we want to consider those
generated resources: do they deserve being regular resources, or are
they somewhat special?

> This would allow you to keep everything the same all the way, but
> *should* vastly speed things up since this will be a subgraph liner DAG
> operation instead of a full graph merge.

For the moment I'll fix the current issue, which is that we don't need
to propagate generated sub-resource events back to them (at least for
the file resources, if there are other generated resources needing this
let me know).

This is clearly a bug in the current implementation, coming from the
fact that the code masquerades the real event generator with the topmost
file resource. If we were sending the events from the subgenerated
resources we wouldn't do that at all. Unfortunately there are
"auto-require" relationships to this topmost node to every generated
sub-file-resources, thus the code "sends" the events back to every
generated sub-file-resources. This makes this algorithm something along
of O(kn^2) with n = number of generated resources, and k number of
different kind of changed events.

I believe it is not necessary to flow those sub-events back to where
they were spawned. The very next fix (coming during the week-end I
think) will make sure those events are propagated only to non-generated
resources. This should fix this issue one for all (we can still keep my
previous patch because it is clearly nicer in terms of memory usage).
-- 
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!

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