So, one of the issues that annoyed the heck out of me ages ago was that when
we got a cycle in our code puppet would generate a large and mostly unhelpful
error message containing an awful lot of junk.
Specifically, it would emit a superset of all resources that were involved in
all cycles in the configuration, then let me try and struggle through to work
out what was going on.
I never submitted a bug report for that, though, so as penance I have gone
ahead and spent some time working to fix that and get more useful output from
the system.
This is about half of what I want to do. It handles the hard parts of the
process, which is to say that we now:
* have an approximation of O(1) performance in processing cycles
* report the minimum set of resources involved in any cycle
* report each cycle detected individually
Technically, the implementation uses Tarjan's algorithm to perform clustering
of the resources if a cycle is detected, and then filters the interesting
cycles out of that; an iterative version of the algorithm is used to ensure
that we don't run into the Ruby limitation on recursion depth if anyone
manages a dependency chain more than 1,250 items long in the real world.
What remains to be done is to improve the output, and aim to make it more
helpful in telling y'all what the actual problem is, not just here to hunt it
down.
Specifically, my next goal is to ensure that we report the shortest path
through the cluster of resources in the cycle, and where there are multiple
equal-length paths we report that sensibly. (eg: a summary, not a thousand
copies of the same information.)
This will solve the situation where you have a cycle that involves, say, every
package in your deployment depending on your apt configuration, and that
ending up with a cycle that results in thousands of resources in the cycle
cluster.
By solve I mean "make it easy to see the first few cycles, and resolve them,
before you get to tackle the rest of them", which should *usually* be the
right information.
Anyway, I would love feedback on the code, especially the implementation. The
non-recursive version of the strong clustering code is exciting, but I am
comfortable that it is basically correct thanks to the testing.
Additional tests to add back in patch 3/4, though, would be grand; the more
scenarios that are verified with the obvious version the happier I will be.
(Though I do trust my ability to transform code. :)
Regards,
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <[email protected]>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons
--
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.
