| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Some spec files like active_record.rb had names that would confuse the
load path and get loaded instead of the intended implentation when the
spec was run from the same directory as the file.
Author: Matt Robinson <matt@puppetlabs.com>
Date: Fri Jun 11 15:29:33 2010 -0700
|
| |
|
|
|
|
|
| |
There are still a few unported tests, but it's at least
better now.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is one less bit that the transaction does.
The resource status objects had nearly enough information
to do everything, so I just added that last bit, and moved
everything over. It's all much cleaner now.
I had to change some existing, internal APIs, but mostly
this should be hidden from outside users.
Signed-off-by: Luke Kanies <luke@reductivelabs.com>
|
| |
|
|
| |
Signed-off-by: Luke Kanies <luke@reductivelabs.com>
|
| |
|
|
|
|
|
|
| |
This includes every event generated in the transaction
and a Resource::Status object for each resource managed,
with per-resource information in it.
Signed-off-by: Luke Kanies <luke@reductivelabs.com>
|
| |
|
|
|
|
|
|
|
| |
We had some no-longer-correct comments in the Transaction
class, which are now removed. This also moves the timestamp
for reports into the report class, so it's created at
initialization by the report, rather than by the transaction.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
|
|
|
| |
This means that every event generated during a transaction,
with all of its metadata, will now be in the report.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
| |
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This option only works when --onetime is specified, as it doesn't make
much sense to worry about exit codes in the context of a long-running
daemon.
This required a refactoring of the existing --detailed-exitcodes code,
as "puppetd" wasn't directly creating a transaction object (like
"puppet" does).
Added Report::exit_status, which did what was previously hard-coded
into the "puppet" executable.
An Agent's "run" method now returns a value (the result of the
individual client class' "run" method)
The "puppetd" agent's "run" method now returns a transaction report, as
that seems like the logical thing to return as the result of applying a
catalog.
Signed-off-by: Deepak Giridharagopal <deepak@brownman.org>
|
| |
|
|
| |
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
|
| |
This provides a single, global bit for determining whether
a given piece of cached data is still valid.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a Request instance into the indirection,
pushing it all the way to the terminus instances. It's
a big commit because it requires modifying every terminus class.
There are still some thorny design issues. In particular, who
should be responsible for making the request object? I've tried
having both the indirection class and the Indirector module creating
it, and both have their issues.
Also, the Catalog class previously allowed passing Node instances
directly to the find method, which is now no longer possible because
the Request class would treat the node as the instance being found.
We need the request class to have two modes, one when it's passed an
instance and one when it's passed a key.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, for example, the configuration terminus that was a
subclass of 'code' would have been stored at
lib/puppet/indirector/code/configuration and would have had
to have been named 'configuration'. Now, the subclass
can be named however the author prefers, and it must be stored
at lib/puppet/indirector/configuration/<name>.rb, where <name>
is the name you've chosen for the terminus type. The name only
matters insomuch as it is used to load the file from disk and
find the appropriate class when asked.
The additional restriction is that the class constant for the terminus
type must have its name as the last word, and the indirection must
be the second to last word. Thus, in our example, we can choose
any class constant that ends with Configuration::Code; given that
there's only one Configuration class at this point, it makes the
most sense to define the class as Puppet::Node::Configuration::Code.
This is somewhat awkward, because of the class's location on disk,
but the only other real option is to autogenerate a
Puppet::Indirector::Configuration class constant, which is, I think,
uglier.
|
|
|
I've provided backward compatibility with the old
handler.
The only terminus type that currently exists for reports
is the 'code' terminus, which is used to process reports
in the style of the old handler. At some point, we should
likely switch at least some of these report types (e.g., 'store')
to terminus types.
|
