| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
We generate the UUID as part of the data collector report, but we didn't
make that available to the node or the chef server otherwise.
Signed-off-by: Thom May <thom@chef.io>
|
| |
|
|
|
|
| |
More Rubymine warnings
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the
best of my knowledge, is covered under an appropriate open
source license and I have the right under that license to
submit that work with modifications, whether created in whole
or in part by me, under the same open source license (unless
I am permitted to submit under a different license), as
Indicated in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including
all personal information I submit with it, including my
sign-off) is maintained indefinitely and may be redistributed
consistent with this project or the open source license(s)
involved.
Signed-off-by: Jason Barnett <jason.w.barnett@gmail.com>
|
| |
|
|
|
|
| |
data-collector message.
Signed-off-by: Josh Hudson <jhudson@chef.io>
|
| |
|
|
|
|
| |
data-collector
Signed-off-by: Josh Hudson <jhudson@chef.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lets make the ResourceReporter smarter, we will try to get the identity
and state (after and before) of the resource but if we can't because of
an Exception, lets sends a message to the data collector containing a
static resource identity since we were unable to generate a proper one.
The problem is coming from the ResourceReporter, when it is trying to
report back the resource identity and state, it is using basic methods
from the Base class that should be secure to call from eny subscriber.
This is actually not a bug since Chef is doing the right thing, that is
to throw an error when the identity property is nil (or is not the right
kind that we configured for) so, rather than making identity properties
smarter for lazy evaluation we are going to make the ResourceReporter a
bit smarter so that it doesn't explode when the use configured a
resource with a wrong identity property.
Closes https://github.com/chef/chef/issues/5490
Signed-off-by: Salim Afiune <afiune@chef.io>
|
| |
|
|
| |
Signed-off-by: Adam Leff <adam@leff.co>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The regex used to pluck the Chef Server Organization from the
chef_server_url config value did not permit hyphens in org names
even though they are allowed by Chef Server. This caused org names
to get incorrectly truncated when sending the payload to Data
Collector servers.
Re: Chef bug IPO-500
Signed-off-by: Adam Leff <adam@leff.co>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
| |
Data Collector uses the json gem to read/write the metadata file
in the file cache. Let's change that to use Chef::JSONCompat instead.
Signed-off-by: Adam Leff <adam@leff.co>
|
| |
|
|
|
|
|
|
|
| |
By adding deprecation warnings to Data Collector, receivers of
Data Collector messages can easily identify nodes that would need
attention to their versions/cookbooks before a major version Chef
upgrade would be successful.
Signed-off-by: Adam Leff <adam@leff.co>
|
| |
|
|
|
|
|
|
|
|
|
| |
If a user configured data_collector.server_url in their Chef config
as an empty string, we blissfully passed it along to Chef::HTTP
which would eventually raise a TypeError when trying to dup the
URI's host. This change validates the server_url when setting up
the Data Collector and gives helpful error messages to the user.
We also count Errno::EHOSTDOWN as an error worthy of disabling
the Data Collector reporter for a given run if the user so chooses.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Many use cases that involve consuming the run_converge messages and
displaying them to end users include needing additional data about
the node that generated the run_converge message. This change
consolidates the run_converge and node_update message into a single
message making it easier for users to filter run_converge messages
based on attributes and criteria of the node itself.
Additionally, the ignore_failure property on a resource is now
included for each resource in the resource list so end users can
decided whether the failure was a hard failure or a soft failure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically when a Chef run fails, the event handlers only report
on resources that have been processed during the run. This change
allows the Data Collector to report those resources in the resource
collection that have not yet been processed so users can better
ascertain how much of their run was completed, and specifically
what resources were not processed as a result of the Chef failure.
Instead of building up a list of resources as they are processed,
this change instead creates a resource report for each resource+action
in the resource collection and then modifies each of those reports
once the resource is processed.
|
| |
|
|
|
|
|
|
|
| |
When we changed the messages from class instances to a module, the
reading of metadata into an instance variable was removed and
introduced a bug when updating metadata. This bug causes the
metadata to be properly read from disk, updated, but then the
metadata from disk is simply re-written to disk without the
intended updates.
|
| |
|
|
|
|
|
|
| |
After adding up-to-date and skipped resources to the DataCollector
resource list, the logic that computed the number of resources
updated needed to change accordingly. This change fixes that
bug and also eliminates an unnecessary counter that tracks
the total number of resources.
|
|
|
The DataCollector reporter is a new method for exporting data about your
Chef run. The details of this new feature can be found in
[RFC 077](https://github.com/chef/chef-rfc/blob/master/rfc077-mode-agnostic-data-collection.md).
Using the existing `EventDispatch` mechanics, the DataCollector reporter
collects data about a Chef run (when it starts, when it ends, what
resources were modified, etc.) and then POSTs them to a Data Collector
server URL that can be specified in your Chef configuration.
While similar functionality exists using the `ResourceReporter` and Chef
Reporting, a new implementation was done to decouple the reporting of this
data from requiring the use of a Chef Server (in the case of Chef Reporting),
opening the door to users being able to implement their own webhook-style
receiver to receive these messages and analyze them accordingly.
|
