| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Ronn doesn't like <param> for some reason.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The manpage generator can now make manpages for the modern executable in
addition to the legacy executables. The section for the legacy
names should be deleted upon the release of 2.8.0.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
We got the rake task working! We're not done, but all the
manpages look a lot better, so let's commit that.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Having this be commented-out code in the installer script doesn't really
make sense for our workflow; we want to be able to regenerate these manpages at will
and make sure they're always up-to-date. This will help us keep them in sync with the help text.
This commit also changes the ronn invocation to specify a manual name and organization.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Clarified how to modify the system state with puppet resource,
and reformatted the markdown for compatibility with ronn.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Puppet queue had inadequate help, so I added to it while
reformatting for ronn.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Forward-porting a fix from 2.6.x to the new help text locations.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Markdown changes for compatibility with ronn.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Markdown changes for compatibility with ronn.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Markdown changes for compatibility with ronn.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The actual text was somewhat disarrayed. No ronn fixes in this patch.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
It's a simple tool, it doesn't need both synopsis and
description. Especially when they're identical.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Markdown changes for compatibility with Ronn.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The puppet apply help was somewhat lacking, so I edited the content
while making its formatting ronn-compatible.
|
| | |/ / / / / / / / /
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Markdown changes for compatibility with Ronn, in the interest of
better manpages.
|
| | |\ \ \ \ \ \ \ \ \
| | | |_|/ / / / / /
| | |/| | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Conflicts:
lib/puppet/util/zaml.rb
|
| | | | | | | | | | | |
|
| | | |\ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
* 2.6.next:
(#6018) Nick F's --help text for puppet inspect.
(#5823) document the not-an-API status of set_run_mode
(#5823) run mode can now be set dynamically...
(6114) Update the audit metaparameter for 2.6.5.
Fix for #5755 -- making zaml serialization robust over projected objects
(#4139) hook log autoflush into global defaults
|
| | | | |\ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
* bug/2.6.next/5755-gc-issue:
Fix for #5755 -- making zaml serialization robust over projected objects
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
The core problem arose when the fix for #5048 in 31118fe85aca4 introduced a
hook to replace objects dynamically durring serialization so that they could be
projected / rewritten to a different form for backward compatability. The
serialization code assumed that all objects being serialized would remain valid
until the serialization was complete, but nothing retained a copy of the
temporary objects created in the hook.
To resolve this, the serialization layer now maintains a ref to each such object
and clears them (to allow GC) after serialization is complete.
Paired-with: Jesse Wolfe <jesse@puppetlabs.com>
Paired-with: Paul Berry <paul@puppetlabs.com>
|
| | |\ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
When the '--graph' option is specified, generate a new 'cycles.dot' file and
report the location of that to the user. This contains only the cycles, in
dot format, allowing a visual representation of the cycle to be obtained
quickly.
This will include up to 10 paths through the cycle in the graph, and only one
in the display to the user, to reduce information overload.
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
A bit of profiling shows that most of the time spent in clustering is spent
trolling around through OpenStruct. Replacing this with a hash or, where
sane, an array for the stack frame in our non-recursive implementations makes
performance significantly faster. (3 seconds to .65 seconds faster.)
I guess those developer niceties do have some cost after all. Better to take
the hit on readability and prefer performance here.
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
This uses a separate hash and array to track the visited path and the seen
vertex data; while that is less efficient than using a single data structure,
it avoids on O(n) operation on the stack to determine if we have previously
visited a vertex.
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
This renames a few cryptic variables to have more human-friendly names, and
aligns a bit of whitespace; there are no functional changes in the code.
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Rather than reporting the cluster of vertexes in the dependency graph, which
is interesting but not entirely informative, we now calculate and report the
paths through the graph that form cycles.
This returns the most useful information, which is the exact path that the
dependency cycle has, allowing the user to (hopefully) immediately target it
and start to work out why the cycle has formed there.
We strongly prefer short paths through the dependency graph within the cycle,
which should report the most useful loops to target first; extended loops
involving more items will show up later if they are independently created.
We also limit the number of paths reported (default: 10) to avoid overwhelming
the error report with the combinatorial explosion that can easily result
from a large scale cycle. (eg: Package => User => Package or something.)
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
The header at the top of the file is long obsolete; simple_graph.rb is
licensed under the GPLv2 like the rest of puppet. Removed.
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
In order to bypass the limitations of the C stack, which is also the Ruby
stack, we replace the simple and clear recursive Trajan implementation with an
iterative version that uses the heap as the stack.
This is somewhat harder to read, but can now run a 10,000 vertex deep linear
dependency relationship where, previously, 1,250 was about the limit on my
machine.
This should now be bounded by the size of the heap rather than the stack on
all platforms -- though it would be nice to get rid of the magic and return to
the recursive version if Ruby ever follows Perl down the sensible path of
essentially unlimited recursion by writing that code for us in the
interpreter...
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
This implements Tarjan's algorithm for finding strongly connected components
in a directed graph, and leverages that to find cycles.
This allows us to report the minimum set of nodes in each cycle, as well as
reporting each cycle discretely if there are multiple of them.
While this can still produce overwhelming and/or unhelpful output, it
represents a large step forward in delivering useful information when a cycle
is detected.
This presently reports the set of nodes that contain the cycle, in no
particular order, rather than the set of edges connecting those nodes.
Sadly, it also suffers a limitation: the implementation of Tarjan's algorithm
used to find strongly connected components is recursive, so is limited by the
maximum Ruby stack depth to dependency chains less than 1,000 nodes deep.
While this is probably not a limit in practice, it is a nasty limitation, and
other considerations (like Ruby stack consumption across versions) could
trigger this much sooner than is desirable.
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Split out the reporting from a single line (often with literally hundreds or
thousands of items) into a multi-line report. This is still nasty, but at
least it is easier to use as input to other systems.
This will also auto-join to a single line when sent to targets such as syslog
that do not approve of newlines in messages; this preserves the utility of the
message without needing to lose console utility.
|
| | |/ / / / / / / / / / /
|/| | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
The SimpleGraph class was reporting duplicate data when printing cycles:
Notify[c]Notify[c] => Notify[d]
Notify[a]Notify[a] => Notify[b]
This was caused by throwing the array representation of the edge into a
string, rather than just the relationship data; we only care about the later,
so now we only emit that later and have the correct text in the error.
|
| |/| | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | |/ / / / / / / / /
| |/| | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
2.6.next
|
| | |/ / / / / / / / / / /
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Since this is totally not API, document that in big, threatening letters so
that folks actually know what is going on. Include promises so they don't
feel too unhappy with us.
Paired-with: matt@puppetlabs.com
|
| | |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
2.6.next
|
