On Mar 19, 2010, at 1:13 AM, Brice Figureau wrote:
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?
IMO, this is the right approach, with some caveats. The only real
concerns I see with it are that we begin to lose some clarity over
what's specifically happening (because we're treating all of the files
as a collection, rather than individually), and if we do have rollback
at some point this will considerably complicate it.
However, I think that as long as we produce events with sufficient
information (i.e., they have to mention both the actual file and the
parent file), we should be able to do rollback without too much
effort, albeit it will require some hackery. That hackery will likely
rarely get used, though, and at this point we're doing way more
hackery in order to get recursive file management in its current form.
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).
There are no other resource types that generate resources mid-
transaction.
Are you sure we don't need to do any propagation? If a service is
subscribed to a file tree and only one change is made but it's lower
in the tree, don't we want that event to propagate?
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).
Ah; that makes sense.
--
Calamities are of two kinds: misfortunes to ourselves, and good
fortune to others. -- Ambrose Bierce
---------------------------------------------------------------------
Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199
--
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.
