Puppet users - Sep 2013 - Announce: PuppetDB 1.5.0 Available

PuppetDB 1.5.0 is now available for download!  This is a new feature
release that contains a few bug-fixes as well.

============## Downloads ##
============
Available in native package format at:
http://yum.puppetlabs.com and http://apt.puppetlabs.com

Puppet module:
http://forge.puppetlabs.com/puppetlabs/puppetdb

Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/

# Documentation (including how to install):
http://docs.puppetlabs.com/puppetdb/1.<http://docs.puppetlabs.com/puppetdb/1.2>
5

# Issues can be filed at:
http://projects.puppetlabs.com/projects/puppetdb/issues


===========================##  PuppetDB 1.5.0 Release Notes  ##
===========================
Notable features and improvements:

* (#21520) Configuration for soft failure when PuppetDB is unavailable

  This feature adds a new option ''soft_write_failure'' to the
puppetdb
  configuration.  If enabled the terminus behavior is changed so that if a
  command or write fails, instead of throwing an exception and causing the
agent
  to stop it will simply log an error to the puppet master log.

* New v3 query API

  New `/v3` URLs are available for all query endpoints.  The `reports` and
  `events` endpoints, which were previously considered `experimental`, have
  been moved into `/v3`.  Most of the other endpoints are 100%
backwards-compatible
  with `/v2`, but now offer additional functionality.  There are few minor
  backwards-incompatible changes, detailed in the comments about individual
  endpoints below.

* Query paging

  This feature adds a set of new HTTP query parameters that can be used
with most
  of the query endpoints (`fact_names`, `facts`, `resources`, `nodes`,
`events`,
  `reports`, `event-counts`) to allow paging through large result sets over
  multiple queries.  The available HTTP query parameters are:

     * `limit`: an integer specifying the maximum number of results to
        return.
     * `order-by`: a list of fields to sort by, in ascending or descending
order.
        The legal set of fields varies by endpoint; see the documentation
for
        individual endpoints for more info.
     * `offset`: an integer specifying the first result in the result set
that
        should be returned.  This can be used in combination with `limit`
        and `order-by` to page through a result set over multiple queries.
     * `include-total`: a boolean flag which, if set, will cause the HTTP
response
       to contain an `X-Records` header indicating the total number of
results that are
       available that match the query.  (Mainly useful in combination with
`limit`.)

* New features available on `events` endpoint

    * The `events` data now contains `file` and `line` fields.  These
indicate
      the location in the manifests where the resource was declared.  They
can
      be used as input to an `events` query.
    * Add new `configuration-version` field, which contains the value that
Puppet
      supplied during the agent run.
    * New `containing-class` field: if the resource is declared inside of a
      Puppet class, this field will contain the name of that class.
    * New `containment-path` field: this field is an array showing the full
      path to the resource from the root of the catalog (contains an ordered
      list of names of the classes/types that the resource is contained
within).
    * New queryable timestamp fields:
        * `run-start-time`: the time (on the agent node) that the run began
        * `run-end-time`: the time (on the agent node) that the run
completed
        * `report-receive-time`: the time (on the puppetdb node) that the
report was received by PuppetDB
    * Restrict results to only include events that occurred in the latest
report
      for a given node: `["=", "latest-report?", true]`

* New `event-counts` endpoint

    `v3` of the query API contains a new `event-counts` endpoint, which can
be
    used to retrieve count data for an event query.  The basic input to the
    endpoint is an event query, just as you''d provide to the `events`
endpoint,
    but rather than returning the actual events, this endpoint returns
counts
    of `successes`, `failures`, `skips`, and `noops` for the events that
match
    the query.  The counts may be aggregated on a per-resource, per-class,
    or per-node basis.

* New `aggregate-event-counts` endpoint

  This endpoint is similar to the `event-counts` endpoint, but rather than
  aggregating the counts on a per-node, per-resource, or per-class basis,
  it returns aggregate counts across your entire population.

* New `server-time` endpoint

  This endpoint simply returns a timestamp indicating the current time on
  the PuppetDB server.  This can be used as input to time-based queries
  against timestamp fields that are populated by PuppetDB.

* Minor changes to `resources` endpoint for `v3`

  The `sourcefile` and `sourceline` fields have been renamed to `file` and
`line`,
  for consistency with other parts of the API.

* Minor changes relating to reports storage and query

  * `store report` command has been bumped up to version `2`.
  * Report data now includes a new `transaction-uuid` field; this is
generated
    by Puppet (as of Puppet 3.3) and can be used to definitively correlate
a report
    with the catalog that was used for the run.  This field is queryable on
the
    `reports` endpoint.
  * Reports now support querying by the field `hash`; this allows you to
retrieve
    data about a given report based on the report hash for an event returned
    by the `events` endpoint.

* Minor changes relating to catalog storage

  * `store catalog` command has been bumped to version `3`.
  * Catalog data now includes the new `transaction-uuid` field; see notes
above.

Bug fixes:

* PuppetDB report processor was truncating microseconds from report
timestamps;
  all timestamp fields should now retain full precision.

* Record resource failures even if Puppet doesn''t generate an event for
them in the
  report: in rare cases, Puppet will generate a report that indicates a
failure
  on a resource but doesn''t actually provide a failure event.  Prior to
PuppetDB
  1.5, the PuppetDB report processor was only checking for the existence of
  events, so these resources would not show up in the PuppetDB report.
 This is
  really a bug in Puppet (which should be fixed as of Puppet 3.3), but the
PuppetDB
  report processor is now smart enough to detect this case and synthesize a
failure
  event for the resource, so that the failure is at least visible in the
PuppetDB
  report data.

* Filter out the well-known "Skipped Schedule" events: in versions of
Puppet prior
  to 3.3, every single agent report would include six events whose status
was
  `skipped` and whose resource type was `Schedule`.  (The titles were
`never`,
  `puppet`, `hourly`, `daily`, `weekly`, and `monthly`.)  These events were
not
  generally useful and caused a great deal of pollution in the PuppetDB
database.
  They are no longer generated as of Puppet 3.3, but for compatibility with
  older versions of Puppet, the report terminus in PuppetDB 1.5 will filter
  these events out before storing the report in PuppetDB.

* Log a message when a request is blocked due to the certificate whitelist:
  prior to 1.5, when a query or command was rejected due to PuppetDB''s
certificate
  whitelist configuration, there was no logging on the server that could be
used
  to troubleshoot the cause of the rejection.  We now log a message, in
hopes of
  making it easier for administrators to track down the cause of
connectivity
  issues in this scenario.

* (#22122) Better log messages when puppetdb-ssl-setup is run before Puppet
  certificates are available.

* (#22159) Fix a bug relating to anonymizing catalog edges in exported
PuppetDB
  data.

* (#22168) Add ability to configure maximum number of threads for Jetty
(having too
  low of a value for this setting on systems with large numbers of cores
could
  prevent Jetty from handling requests).

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

No packages for precise/raring? Its missing debs for 1.5.0. Lucid seems fine

Thanks,
William


On Mon, Sep 30, 2013 at 4:56 PM, Chris Price <chris@puppetlabs.com> wrote:
> PuppetDB 1.5.0 is now available for download!  This is a new feature
> release that contains a few bug-fixes as well.
>
> ============> ## Downloads ##
> ============>
> Available in native package format at:
> http://yum.puppetlabs.com and http://apt.puppetlabs.com
>
> Puppet module:
> http://forge.puppetlabs.com/puppetlabs/puppetdb
>
> Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/
>
> # Documentation (including how to install):
>
http://docs.puppetlabs.com/puppetdb/1.<http://docs.puppetlabs.com/puppetdb/1.2>
> 5
>
> # Issues can be filed at:
> http://projects.puppetlabs.com/projects/puppetdb/issues
>
>
> ===========================> ##  PuppetDB 1.5.0 Release Notes  ##
> ===========================>
> Notable features and improvements:
>
> * (#21520) Configuration for soft failure when PuppetDB is unavailable
>
>   This feature adds a new option ''soft_write_failure'' to
the puppetdb
>   configuration.  If enabled the terminus behavior is changed so that if a
>   command or write fails, instead of throwing an exception and causing the
> agent
>   to stop it will simply log an error to the puppet master log.
>
> * New v3 query API
>
>   New `/v3` URLs are available for all query endpoints.  The `reports` and
>   `events` endpoints, which were previously considered `experimental`, have
>   been moved into `/v3`.  Most of the other endpoints are 100%
> backwards-compatible
>   with `/v2`, but now offer additional functionality.  There are few minor
>   backwards-incompatible changes, detailed in the comments about individual
>   endpoints below.
>
> * Query paging
>
>   This feature adds a set of new HTTP query parameters that can be used
> with most
>   of the query endpoints (`fact_names`, `facts`, `resources`, `nodes`,
> `events`,
>   `reports`, `event-counts`) to allow paging through large result sets over
>   multiple queries.  The available HTTP query parameters are:
>
>      * `limit`: an integer specifying the maximum number of results to
>         return.
>      * `order-by`: a list of fields to sort by, in ascending or descending
> order.
>         The legal set of fields varies by endpoint; see the documentation
> for
>         individual endpoints for more info.
>      * `offset`: an integer specifying the first result in the result set
> that
>         should be returned.  This can be used in combination with `limit`
>         and `order-by` to page through a result set over multiple queries.
>      * `include-total`: a boolean flag which, if set, will cause the HTTP
> response
>        to contain an `X-Records` header indicating the total number of
> results that are
>        available that match the query.  (Mainly useful in combination with
> `limit`.)
>
> * New features available on `events` endpoint
>
>     * The `events` data now contains `file` and `line` fields.  These
> indicate
>       the location in the manifests where the resource was declared.  They
> can
>       be used as input to an `events` query.
>     * Add new `configuration-version` field, which contains the value that
> Puppet
>       supplied during the agent run.
>     * New `containing-class` field: if the resource is declared inside of a
>       Puppet class, this field will contain the name of that class.
>     * New `containment-path` field: this field is an array showing the full
>       path to the resource from the root of the catalog (contains an
> ordered
>       list of names of the classes/types that the resource is contained
> within).
>     * New queryable timestamp fields:
>         * `run-start-time`: the time (on the agent node) that the run began
>         * `run-end-time`: the time (on the agent node) that the run
> completed
>         * `report-receive-time`: the time (on the puppetdb node) that the
> report was received by PuppetDB
>     * Restrict results to only include events that occurred in the latest
> report
>       for a given node: `["=", "latest-report?", true]`
>
> * New `event-counts` endpoint
>
>     `v3` of the query API contains a new `event-counts` endpoint, which
> can be
>     used to retrieve count data for an event query.  The basic input to the
>     endpoint is an event query, just as you''d provide to the
`events`
> endpoint,
>     but rather than returning the actual events, this endpoint returns
> counts
>     of `successes`, `failures`, `skips`, and `noops` for the events that
> match
>     the query.  The counts may be aggregated on a per-resource, per-class,
>     or per-node basis.
>
> * New `aggregate-event-counts` endpoint
>
>   This endpoint is similar to the `event-counts` endpoint, but rather than
>   aggregating the counts on a per-node, per-resource, or per-class basis,
>   it returns aggregate counts across your entire population.
>
> * New `server-time` endpoint
>
>   This endpoint simply returns a timestamp indicating the current time on
>   the PuppetDB server.  This can be used as input to time-based queries
>   against timestamp fields that are populated by PuppetDB.
>
> * Minor changes to `resources` endpoint for `v3`
>
>   The `sourcefile` and `sourceline` fields have been renamed to `file` and
> `line`,
>   for consistency with other parts of the API.
>
> * Minor changes relating to reports storage and query
>
>   * `store report` command has been bumped up to version `2`.
>   * Report data now includes a new `transaction-uuid` field; this is
> generated
>     by Puppet (as of Puppet 3.3) and can be used to definitively correlate
> a report
>     with the catalog that was used for the run.  This field is queryable
> on the
>     `reports` endpoint.
>   * Reports now support querying by the field `hash`; this allows you to
> retrieve
>     data about a given report based on the report hash for an event
> returned
>     by the `events` endpoint.
>
> * Minor changes relating to catalog storage
>
>   * `store catalog` command has been bumped to version `3`.
>   * Catalog data now includes the new `transaction-uuid` field; see notes
> above.
>
> Bug fixes:
>
> * PuppetDB report processor was truncating microseconds from report
> timestamps;
>   all timestamp fields should now retain full precision.
>
> * Record resource failures even if Puppet doesn''t generate an
event for
> them in the
>   report: in rare cases, Puppet will generate a report that indicates a
> failure
>   on a resource but doesn''t actually provide a failure event. 
Prior to
> PuppetDB
>   1.5, the PuppetDB report processor was only checking for the existence of
>   events, so these resources would not show up in the PuppetDB report.
>  This is
>   really a bug in Puppet (which should be fixed as of Puppet 3.3), but the
> PuppetDB
>   report processor is now smart enough to detect this case and synthesize
> a failure
>   event for the resource, so that the failure is at least visible in the
> PuppetDB
>   report data.
>
> * Filter out the well-known "Skipped Schedule" events: in
versions of
> Puppet prior
>   to 3.3, every single agent report would include six events whose status
> was
>   `skipped` and whose resource type was `Schedule`.  (The titles were
> `never`,
>   `puppet`, `hourly`, `daily`, `weekly`, and `monthly`.)  These events
> were not
>   generally useful and caused a great deal of pollution in the PuppetDB
> database.
>   They are no longer generated as of Puppet 3.3, but for compatibility with
>   older versions of Puppet, the report terminus in PuppetDB 1.5 will filter
>   these events out before storing the report in PuppetDB.
>
> * Log a message when a request is blocked due to the certificate whitelist:
>   prior to 1.5, when a query or command was rejected due to
PuppetDB''s
> certificate
>   whitelist configuration, there was no logging on the server that could
> be used
>   to troubleshoot the cause of the rejection.  We now log a message, in
> hopes of
>   making it easier for administrators to track down the cause of
> connectivity
>   issues in this scenario.
>
> * (#22122) Better log messages when puppetdb-ssl-setup is run before Puppet
>   certificates are available.
>
> * (#22159) Fix a bug relating to anonymizing catalog edges in exported
> PuppetDB
>   data.
>
> * (#22168) Add ability to configure maximum number of threads for Jetty
> (having too
>   low of a value for this setting on systems with large numbers of cores
> could
>   prevent Jetty from handling requests).
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-dev@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-dev.
> For more options, visit https://groups.google.com/groups/opt_out.
>


-- 
Thanks,
William

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Oh goody this looks awesome.

-- 
Daniele Sluijters

On Tuesday, 1 October 2013 01:56:49 UTC+2, Chris Price
wrote:
>
> PuppetDB 1.5.0 is now available for download!  This is a new feature 
> release that contains a few bug-fixes as well.
>
> ============= 
> ## Downloads ## 
> ============= 
>
> Available in native package format at: 
> http://yum.puppetlabs.com and http://apt.puppetlabs.com 
>
> Puppet module: 
> http://forge.puppetlabs.com/puppetlabs/puppetdb 
>
> Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/ 
>
> # Documentation (including how to install): 
>
http://docs.puppetlabs.com/puppetdb/1.<http://docs.puppetlabs.com/puppetdb/1.2>
> 5
>
> # Issues can be filed at: 
> http://projects.puppetlabs.com/projects/puppetdb/issues 
>
>
> ============================ 
> ##  PuppetDB 1.5.0 Release Notes  ## 
> ============================ 
>
> Notable features and improvements:
>
> * (#21520) Configuration for soft failure when PuppetDB is unavailable
>
>   This feature adds a new option ''soft_write_failure'' to
the puppetdb
>   configuration.  If enabled the terminus behavior is changed so that if a
>   command or write fails, instead of throwing an exception and causing the 
> agent
>   to stop it will simply log an error to the puppet master log.
>
> * New v3 query API
>
>   New `/v3` URLs are available for all query endpoints.  The `reports` and
>   `events` endpoints, which were previously considered `experimental`, have
>   been moved into `/v3`.  Most of the other endpoints are 100% 
> backwards-compatible
>   with `/v2`, but now offer additional functionality.  There are few minor
>   backwards-incompatible changes, detailed in the comments about individual
>   endpoints below.
>
> * Query paging
>
>   This feature adds a set of new HTTP query parameters that can be used 
> with most
>   of the query endpoints (`fact_names`, `facts`, `resources`, `nodes`, 
> `events`,
>   `reports`, `event-counts`) to allow paging through large result sets over
>   multiple queries.  The available HTTP query parameters are:
>
>      * `limit`: an integer specifying the maximum number of results to
>         return.
>      * `order-by`: a list of fields to sort by, in ascending or descending 
> order.
>         The legal set of fields varies by endpoint; see the documentation 
> for
>         individual endpoints for more info.
>      * `offset`: an integer specifying the first result in the result set 
> that
>         should be returned.  This can be used in combination with `limit`
>         and `order-by` to page through a result set over multiple queries.
>      * `include-total`: a boolean flag which, if set, will cause the HTTP 
> response
>        to contain an `X-Records` header indicating the total number of 
> results that are
>        available that match the query.  (Mainly useful in combination with 
> `limit`.)
>
> * New features available on `events` endpoint
>
>     * The `events` data now contains `file` and `line` fields.  These 
> indicate
>       the location in the manifests where the resource was declared.  They 
> can
>       be used as input to an `events` query.
>     * Add new `configuration-version` field, which contains the value that 
> Puppet
>       supplied during the agent run.
>     * New `containing-class` field: if the resource is declared inside of a
>       Puppet class, this field will contain the name of that class.
>     * New `containment-path` field: this field is an array showing the full
>       path to the resource from the root of the catalog (contains an 
> ordered
>       list of names of the classes/types that the resource is contained 
> within).
>     * New queryable timestamp fields:
>         * `run-start-time`: the time (on the agent node) that the run began
>         * `run-end-time`: the time (on the agent node) that the run 
> completed
>         * `report-receive-time`: the time (on the puppetdb node) that the 
> report was received by PuppetDB
>     * Restrict results to only include events that occurred in the latest 
> report
>       for a given node: `["=", "latest-report?", true]`
>
> * New `event-counts` endpoint
>
>     `v3` of the query API contains a new `event-counts` endpoint, which 
> can be
>     used to retrieve count data for an event query.  The basic input to the
>     endpoint is an event query, just as you''d provide to the
`events`
> endpoint,
>     but rather than returning the actual events, this endpoint returns 
> counts
>     of `successes`, `failures`, `skips`, and `noops` for the events that 
> match
>     the query.  The counts may be aggregated on a per-resource, per-class,
>     or per-node basis.
>
> * New `aggregate-event-counts` endpoint
>
>   This endpoint is similar to the `event-counts` endpoint, but rather than
>   aggregating the counts on a per-node, per-resource, or per-class basis,
>   it returns aggregate counts across your entire population.
>
> * New `server-time` endpoint
>
>   This endpoint simply returns a timestamp indicating the current time on
>   the PuppetDB server.  This can be used as input to time-based queries
>   against timestamp fields that are populated by PuppetDB.
>
> * Minor changes to `resources` endpoint for `v3`
>
>   The `sourcefile` and `sourceline` fields have been renamed to `file` and 
> `line`,
>   for consistency with other parts of the API.
>
> * Minor changes relating to reports storage and query
>
>   * `store report` command has been bumped up to version `2`.
>   * Report data now includes a new `transaction-uuid` field; this is 
> generated
>     by Puppet (as of Puppet 3.3) and can be used to definitively correlate 
> a report
>     with the catalog that was used for the run.  This field is queryable 
> on the
>     `reports` endpoint.
>   * Reports now support querying by the field `hash`; this allows you to 
> retrieve
>     data about a given report based on the report hash for an event 
> returned
>     by the `events` endpoint.
>
> * Minor changes relating to catalog storage
>
>   * `store catalog` command has been bumped to version `3`.
>   * Catalog data now includes the new `transaction-uuid` field; see notes 
> above.
>
> Bug fixes:
>
> * PuppetDB report processor was truncating microseconds from report 
> timestamps;
>   all timestamp fields should now retain full precision.
>
> * Record resource failures even if Puppet doesn''t generate an
event for
> them in the
>   report: in rare cases, Puppet will generate a report that indicates a 
> failure
>   on a resource but doesn''t actually provide a failure event. 
Prior to
> PuppetDB
>   1.5, the PuppetDB report processor was only checking for the existence of
>   events, so these resources would not show up in the PuppetDB report. 
>  This is
>   really a bug in Puppet (which should be fixed as of Puppet 3.3), but the 
> PuppetDB
>   report processor is now smart enough to detect this case and synthesize 
> a failure
>   event for the resource, so that the failure is at least visible in the 
> PuppetDB
>   report data.
>
> * Filter out the well-known "Skipped Schedule" events: in
versions of
> Puppet prior
>   to 3.3, every single agent report would include six events whose status 
> was
>   `skipped` and whose resource type was `Schedule`.  (The titles were 
> `never`,
>   `puppet`, `hourly`, `daily`, `weekly`, and `monthly`.)  These events 
> were not
>   generally useful and caused a great deal of pollution in the PuppetDB 
> database.
>   They are no longer generated as of Puppet 3.3, but for compatibility with
>   older versions of Puppet, the report terminus in PuppetDB 1.5 will filter
>   these events out before storing the report in PuppetDB.
>
> * Log a message when a request is blocked due to the certificate whitelist:
>   prior to 1.5, when a query or command was rejected due to
PuppetDB''s
> certificate
>   whitelist configuration, there was no logging on the server that could 
> be used
>   to troubleshoot the cause of the rejection.  We now log a message, in 
> hopes of
>   making it easier for administrators to track down the cause of 
> connectivity
>   issues in this scenario.
>
> * (#22122) Better log messages when puppetdb-ssl-setup is run before Puppet
>   certificates are available.
>
> * (#22159) Fix a bug relating to anonymizing catalog edges in exported 
> PuppetDB
>   data.
>
> * (#22168) Add ability to configure maximum number of threads for Jetty 
> (having too
>   low of a value for this setting on systems with large numbers of cores 
> could
>   prevent Jetty from handling requests).
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

indeed, should make it a lot easier to create performant interfaces to it.
Time to update all the query tools and libraries it looks like :)


On 1 October 2013 09:19, Daniele Sluijters
<daniele.sluijters@gmail.com>wrote:
> Oh goody this looks awesome.
>
> --
> Daniele Sluijters
>
>
> On Tuesday, 1 October 2013 01:56:49 UTC+2, Chris Price wrote:
>>
>> PuppetDB 1.5.0 is now available for download!  This is a new feature
>> release that contains a few bug-fixes as well.
>>
>> ============>> ## Downloads ##
>> ============>>
>> Available in native package format at:
>> http://yum.puppetlabs.com and
**http://apt.puppetlabs.com<http://apt.puppetlabs.com/>
>>
>>
>> Puppet module:
>>
http://forge.puppetlabs.com/**puppetlabs/puppetdb<http://forge.puppetlabs.com/puppetlabs/puppetdb>
>>
>>
>> Source (same license as Puppet):
http://github.com/**puppetlabs/puppetdb/<http://github.com/puppetlabs/puppetdb/>
>>
>>
>> # Documentation (including how to install):
>>
http://docs.puppetlabs.com/pup**petdb/1.<http://docs.puppetlabs.com/puppetdb/1.2>
>> 5
>>
>> # Issues can be filed at:
>>
http://projects.puppetlabs.**com/projects/puppetdb/issues<http://projects.puppetlabs.com/projects/puppetdb/issues>
>>
>>
>>
>> ===========================>> ##  PuppetDB 1.5.0 Release Notes 
##
>> ===========================>>
>> Notable features and improvements:
>>
>> * (#21520) Configuration for soft failure when PuppetDB is unavailable
>>
>>   This feature adds a new option ''soft_write_failure''
to the puppetdb
>>   configuration.  If enabled the terminus behavior is changed so that
if a
>>   command or write fails, instead of throwing an exception and causing
>> the agent
>>   to stop it will simply log an error to the puppet master log.
>>
>> * New v3 query API
>>
>>   New `/v3` URLs are available for all query endpoints.  The `reports`
and
>>   `events` endpoints, which were previously considered `experimental`,
>> have
>>   been moved into `/v3`.  Most of the other endpoints are 100%
>> backwards-compatible
>>   with `/v2`, but now offer additional functionality.  There are few
minor
>>   backwards-incompatible changes, detailed in the comments about
>> individual
>>   endpoints below.
>>
>> * Query paging
>>
>>   This feature adds a set of new HTTP query parameters that can be used
>> with most
>>   of the query endpoints (`fact_names`, `facts`, `resources`, `nodes`,
>> `events`,
>>   `reports`, `event-counts`) to allow paging through large result sets
>> over
>>   multiple queries.  The available HTTP query parameters are:
>>
>>      * `limit`: an integer specifying the maximum number of results to
>>         return.
>>      * `order-by`: a list of fields to sort by, in ascending or
>> descending order.
>>         The legal set of fields varies by endpoint; see the
documentation
>> for
>>         individual endpoints for more info.
>>      * `offset`: an integer specifying the first result in the result
set
>> that
>>         should be returned.  This can be used in combination with
`limit`
>>         and `order-by` to page through a result set over multiple
queries.
>>      * `include-total`: a boolean flag which, if set, will cause the
HTTP
>> response
>>        to contain an `X-Records` header indicating the total number of
>> results that are
>>        available that match the query.  (Mainly useful in combination
>> with `limit`.)
>>
>> * New features available on `events` endpoint
>>
>>     * The `events` data now contains `file` and `line` fields.  These
>> indicate
>>       the location in the manifests where the resource was declared.
>>  They can
>>       be used as input to an `events` query.
>>     * Add new `configuration-version` field, which contains the value
>> that Puppet
>>       supplied during the agent run.
>>     * New `containing-class` field: if the resource is declared inside
of
>> a
>>       Puppet class, this field will contain the name of that class.
>>     * New `containment-path` field: this field is an array showing the
>> full
>>       path to the resource from the root of the catalog (contains an
>> ordered
>>       list of names of the classes/types that the resource is contained
>> within).
>>     * New queryable timestamp fields:
>>         * `run-start-time`: the time (on the agent node) that the run
>> began
>>         * `run-end-time`: the time (on the agent node) that the run
>> completed
>>         * `report-receive-time`: the time (on the puppetdb node) that
the
>> report was received by PuppetDB
>>     * Restrict results to only include events that occurred in the
latest
>> report
>>       for a given node: `["=", "latest-report?",
true]`
>>
>> * New `event-counts` endpoint
>>
>>     `v3` of the query API contains a new `event-counts` endpoint, which
>> can be
>>     used to retrieve count data for an event query.  The basic input to
>> the
>>     endpoint is an event query, just as you''d provide to the
`events`
>> endpoint,
>>     but rather than returning the actual events, this endpoint returns
>> counts
>>     of `successes`, `failures`, `skips`, and `noops` for the events
that
>> match
>>     the query.  The counts may be aggregated on a per-resource,
per-class,
>>     or per-node basis.
>>
>> * New `aggregate-event-counts` endpoint
>>
>>   This endpoint is similar to the `event-counts` endpoint, but rather
than
>>   aggregating the counts on a per-node, per-resource, or per-class
basis,
>>   it returns aggregate counts across your entire population.
>>
>> * New `server-time` endpoint
>>
>>   This endpoint simply returns a timestamp indicating the current time
on
>>   the PuppetDB server.  This can be used as input to time-based queries
>>   against timestamp fields that are populated by PuppetDB.
>>
>> * Minor changes to `resources` endpoint for `v3`
>>
>>   The `sourcefile` and `sourceline` fields have been renamed to `file`
>> and `line`,
>>   for consistency with other parts of the API.
>>
>> * Minor changes relating to reports storage and query
>>
>>   * `store report` command has been bumped up to version `2`.
>>   * Report data now includes a new `transaction-uuid` field; this is
>> generated
>>     by Puppet (as of Puppet 3.3) and can be used to definitively
>> correlate a report
>>     with the catalog that was used for the run.  This field is
queryable
>> on the
>>     `reports` endpoint.
>>   * Reports now support querying by the field `hash`; this allows you
to
>> retrieve
>>     data about a given report based on the report hash for an event
>> returned
>>     by the `events` endpoint.
>>
>> * Minor changes relating to catalog storage
>>
>>   * `store catalog` command has been bumped to version `3`.
>>   * Catalog data now includes the new `transaction-uuid` field; see
notes
>> above.
>>
>> Bug fixes:
>>
>> * PuppetDB report processor was truncating microseconds from report
>> timestamps;
>>   all timestamp fields should now retain full precision.
>>
>> * Record resource failures even if Puppet doesn''t generate an
event for
>> them in the
>>   report: in rare cases, Puppet will generate a report that indicates a
>> failure
>>   on a resource but doesn''t actually provide a failure event. 
Prior to
>> PuppetDB
>>   1.5, the PuppetDB report processor was only checking for the
existence
>> of
>>   events, so these resources would not show up in the PuppetDB report.
>>  This is
>>   really a bug in Puppet (which should be fixed as of Puppet 3.3), but
>> the PuppetDB
>>   report processor is now smart enough to detect this case and
synthesize
>> a failure
>>   event for the resource, so that the failure is at least visible in
the
>> PuppetDB
>>   report data.
>>
>> * Filter out the well-known "Skipped Schedule" events: in
versions of
>> Puppet prior
>>   to 3.3, every single agent report would include six events whose
status
>> was
>>   `skipped` and whose resource type was `Schedule`.  (The titles were
>> `never`,
>>   `puppet`, `hourly`, `daily`, `weekly`, and `monthly`.)  These events
>> were not
>>   generally useful and caused a great deal of pollution in the PuppetDB
>> database.
>>   They are no longer generated as of Puppet 3.3, but for compatibility
>> with
>>   older versions of Puppet, the report terminus in PuppetDB 1.5 will
>> filter
>>   these events out before storing the report in PuppetDB.
>>
>> * Log a message when a request is blocked due to the certificate
>> whitelist:
>>   prior to 1.5, when a query or command was rejected due to
PuppetDB''s
>> certificate
>>   whitelist configuration, there was no logging on the server that
could
>> be used
>>   to troubleshoot the cause of the rejection.  We now log a message, in
>> hopes of
>>   making it easier for administrators to track down the cause of
>> connectivity
>>   issues in this scenario.
>>
>> * (#22122) Better log messages when puppetdb-ssl-setup is run before
>> Puppet
>>   certificates are available.
>>
>> * (#22159) Fix a bug relating to anonymizing catalog edges in exported
>> PuppetDB
>>   data.
>>
>> * (#22168) Add ability to configure maximum number of threads for Jetty
>> (having too
>>   low of a value for this setting on systems with large numbers of
cores
>> could
>>   prevent Jetty from handling requests).
>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-dev@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-dev.
> For more options, visit https://groups.google.com/groups/opt_out.
>


-- 
Erik Dalén

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

It''s not just the Precise packages that are missing. The complete
Debian
suite is missing too, squeeze, wheezy, jessy and sid.

On Tuesday, 1 October 2013 04:59:16 UTC+2, blkperl
wrote:
>
> No packages for precise/raring? Its missing debs for 1.5.0. Lucid seems 
> fine
>
> Thanks,
> William
>
>
> On Mon, Sep 30, 2013 at 4:56 PM, Chris Price
<ch...@puppetlabs.com<javascript:>
> > wrote:
>
>> PuppetDB 1.5.0 is now available for download!  This is a new feature 
>> release that contains a few bug-fixes as well.
>>
>> ============= 
>> ## Downloads ## 
>> ============= 
>>
>> Available in native package format at: 
>> http://yum.puppetlabs.com and http://apt.puppetlabs.com 
>>
>> Puppet module: 
>> http://forge.puppetlabs.com/puppetlabs/puppetdb 
>>
>> Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/
>>
>> # Documentation (including how to install): 
>>
http://docs.puppetlabs.com/puppetdb/1.<http://docs.puppetlabs.com/puppetdb/1.2>
>> 5
>>
>> # Issues can be filed at: 
>> http://projects.puppetlabs.com/projects/puppetdb/issues 
>>
>>
>> ============================ 
>> ##  PuppetDB 1.5.0 Release Notes  ## 
>> ============================ 
>>
>> Notable features and improvements:
>>
>> * (#21520) Configuration for soft failure when PuppetDB is unavailable
>>
>>   This feature adds a new option ''soft_write_failure''
to the puppetdb
>>   configuration.  If enabled the terminus behavior is changed so that
if a
>>   command or write fails, instead of throwing an exception and causing 
>> the agent
>>   to stop it will simply log an error to the puppet master log.
>>
>> * New v3 query API
>>
>>   New `/v3` URLs are available for all query endpoints.  The `reports`
and
>>   `events` endpoints, which were previously considered `experimental`, 
>> have
>>   been moved into `/v3`.  Most of the other endpoints are 100% 
>> backwards-compatible
>>   with `/v2`, but now offer additional functionality.  There are few
minor
>>   backwards-incompatible changes, detailed in the comments about 
>> individual
>>   endpoints below.
>>
>> * Query paging
>>
>>   This feature adds a set of new HTTP query parameters that can be used
>> with most
>>   of the query endpoints (`fact_names`, `facts`, `resources`, `nodes`, 
>> `events`,
>>   `reports`, `event-counts`) to allow paging through large result sets 
>> over
>>   multiple queries.  The available HTTP query parameters are:
>>
>>      * `limit`: an integer specifying the maximum number of results to
>>         return.
>>      * `order-by`: a list of fields to sort by, in ascending or 
>> descending order.
>>         The legal set of fields varies by endpoint; see the
documentation
>> for
>>         individual endpoints for more info.
>>      * `offset`: an integer specifying the first result in the result
set
>> that
>>         should be returned.  This can be used in combination with
`limit`
>>         and `order-by` to page through a result set over multiple
queries.
>>      * `include-total`: a boolean flag which, if set, will cause the
HTTP
>> response
>>        to contain an `X-Records` header indicating the total number of 
>> results that are
>>        available that match the query.  (Mainly useful in combination 
>> with `limit`.)
>>
>> * New features available on `events` endpoint
>>
>>     * The `events` data now contains `file` and `line` fields.  These 
>> indicate
>>       the location in the manifests where the resource was declared. 
>>  They can
>>       be used as input to an `events` query.
>>     * Add new `configuration-version` field, which contains the value 
>> that Puppet
>>       supplied during the agent run.
>>     * New `containing-class` field: if the resource is declared inside
of
>> a
>>       Puppet class, this field will contain the name of that class.
>>     * New `containment-path` field: this field is an array showing the 
>> full
>>       path to the resource from the root of the catalog (contains an 
>> ordered
>>       list of names of the classes/types that the resource is contained
>> within).
>>     * New queryable timestamp fields:
>>         * `run-start-time`: the time (on the agent node) that the run 
>> began
>>         * `run-end-time`: the time (on the agent node) that the run 
>> completed
>>         * `report-receive-time`: the time (on the puppetdb node) that
the
>> report was received by PuppetDB
>>     * Restrict results to only include events that occurred in the
latest
>> report
>>       for a given node: `["=", "latest-report?",
true]`
>>
>> * New `event-counts` endpoint
>>
>>     `v3` of the query API contains a new `event-counts` endpoint, which
>> can be
>>     used to retrieve count data for an event query.  The basic input to
>> the
>>     endpoint is an event query, just as you''d provide to the
`events`
>> endpoint,
>>     but rather than returning the actual events, this endpoint returns 
>> counts
>>     of `successes`, `failures`, `skips`, and `noops` for the events
that
>> match
>>     the query.  The counts may be aggregated on a per-resource,
per-class,
>>     or per-node basis.
>>
>> * New `aggregate-event-counts` endpoint
>>
>>   This endpoint is similar to the `event-counts` endpoint, but rather
than
>>   aggregating the counts on a per-node, per-resource, or per-class
basis,
>>   it returns aggregate counts across your entire population.
>>
>> * New `server-time` endpoint
>>
>>   This endpoint simply returns a timestamp indicating the current time
on
>>   the PuppetDB server.  This can be used as input to time-based queries
>>   against timestamp fields that are populated by PuppetDB.
>>
>> * Minor changes to `resources` endpoint for `v3`
>>
>>   The `sourcefile` and `sourceline` fields have been renamed to `file` 
>> and `line`,
>>   for consistency with other parts of the API.
>>
>> * Minor changes relating to reports storage and query
>>
>>   * `store report` command has been bumped up to version `2`.
>>   * Report data now includes a new `transaction-uuid` field; this is 
>> generated
>>     by Puppet (as of Puppet 3.3) and can be used to definitively 
>> correlate a report
>>     with the catalog that was used for the run.  This field is
queryable
>> on the
>>     `reports` endpoint.
>>   * Reports now support querying by the field `hash`; this allows you
to
>> retrieve
>>     data about a given report based on the report hash for an event 
>> returned
>>     by the `events` endpoint.
>>
>> * Minor changes relating to catalog storage
>>
>>   * `store catalog` command has been bumped to version `3`.
>>   * Catalog data now includes the new `transaction-uuid` field; see
notes
>> above.
>>
>> Bug fixes:
>>
>> * PuppetDB report processor was truncating microseconds from report 
>> timestamps;
>>   all timestamp fields should now retain full precision.
>>
>> * Record resource failures even if Puppet doesn''t generate an
event for
>> them in the
>>   report: in rare cases, Puppet will generate a report that indicates a
>> failure
>>   on a resource but doesn''t actually provide a failure event. 
Prior to
>> PuppetDB
>>   1.5, the PuppetDB report processor was only checking for the
existence
>> of
>>   events, so these resources would not show up in the PuppetDB report. 
>>  This is
>>   really a bug in Puppet (which should be fixed as of Puppet 3.3), but 
>> the PuppetDB
>>   report processor is now smart enough to detect this case and
synthesize
>> a failure
>>   event for the resource, so that the failure is at least visible in
the
>> PuppetDB
>>   report data.
>>
>> * Filter out the well-known "Skipped Schedule" events: in
versions of
>> Puppet prior
>>   to 3.3, every single agent report would include six events whose
status
>> was
>>   `skipped` and whose resource type was `Schedule`.  (The titles were 
>> `never`,
>>   `puppet`, `hourly`, `daily`, `weekly`, and `monthly`.)  These events 
>> were not
>>   generally useful and caused a great deal of pollution in the PuppetDB
>> database.
>>   They are no longer generated as of Puppet 3.3, but for compatibility 
>> with
>>   older versions of Puppet, the report terminus in PuppetDB 1.5 will 
>> filter
>>   these events out before storing the report in PuppetDB.
>>
>> * Log a message when a request is blocked due to the certificate 
>> whitelist:
>>   prior to 1.5, when a query or command was rejected due to
PuppetDB''s
>> certificate
>>   whitelist configuration, there was no logging on the server that
could
>> be used
>>   to troubleshoot the cause of the rejection.  We now log a message, in
>> hopes of
>>   making it easier for administrators to track down the cause of 
>> connectivity
>>   issues in this scenario.
>>
>> * (#22122) Better log messages when puppetdb-ssl-setup is run before 
>> Puppet
>>   certificates are available.
>>
>> * (#22159) Fix a bug relating to anonymizing catalog edges in exported 
>> PuppetDB
>>   data.
>>
>> * (#22168) Add ability to configure maximum number of threads for Jetty
>> (having too
>>   low of a value for this setting on systems with large numbers of
cores
>> could
>>   prevent Jetty from handling requests).
>>
>>  
>>  -- 
>> You received this message because you are subscribed to the Google
Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an
>> email to puppet-dev+...@googlegroups.com <javascript:>.
>> To post to this group, send email to
puppe...@googlegroups.com<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/puppet-dev.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> Thanks,
> William
>  
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Hmm ... thanks for letting us know.

My humblest apologies, we''ll get the updates out for those distro
releases ASAP. As Daniele mentioned, on apt.puppetlabs.com it seems
only lucid is available now, the others releases are missing.

ken.

On Tue, Oct 1, 2013 at 9:56 AM, Daniele Sluijters
<daniele.sluijters@gmail.com> wrote:
> It''s not just the Precise packages that are missing. The complete
Debian
> suite is missing too, squeeze, wheezy, jessy and sid.
>
>
> On Tuesday, 1 October 2013 04:59:16 UTC+2, blkperl wrote:
>>
>> No packages for precise/raring? Its missing debs for 1.5.0. Lucid seems
>> fine
>>
>> Thanks,
>> William
>>
>>
>> On Mon, Sep 30, 2013 at 4:56 PM, Chris Price
<ch...@puppetlabs.com> wrote:
>>>
>>> PuppetDB 1.5.0 is now available for download!  This is a new
feature
>>> release that contains a few bug-fixes as well.
>>>
>>> ============>>> ## Downloads ##
>>> ============>>>
>>> Available in native package format at:
>>> http://yum.puppetlabs.com and http://apt.puppetlabs.com
>>>
>>> Puppet module:
>>> http://forge.puppetlabs.com/puppetlabs/puppetdb
>>>
>>> Source (same license as Puppet):
http://github.com/puppetlabs/puppetdb/
>>>
>>> # Documentation (including how to install):
>>> http://docs.puppetlabs.com/puppetdb/1.5
>>>
>>> # Issues can be filed at:
>>> http://projects.puppetlabs.com/projects/puppetdb/issues
>>>
>>>
>>> ===========================>>> ##  PuppetDB 1.5.0 Release
Notes  ##
>>> ===========================>>>
>>> Notable features and improvements:
>>>
>>> * (#21520) Configuration for soft failure when PuppetDB is
unavailable
>>>
>>>   This feature adds a new option
''soft_write_failure'' to the puppetdb
>>>   configuration.  If enabled the terminus behavior is changed so
that if
>>> a
>>>   command or write fails, instead of throwing an exception and
causing
>>> the agent
>>>   to stop it will simply log an error to the puppet master log.
>>>
>>> * New v3 query API
>>>
>>>   New `/v3` URLs are available for all query endpoints.  The
`reports`
>>> and
>>>   `events` endpoints, which were previously considered
`experimental`,
>>> have
>>>   been moved into `/v3`.  Most of the other endpoints are 100%
>>> backwards-compatible
>>>   with `/v2`, but now offer additional functionality.  There are
few
>>> minor
>>>   backwards-incompatible changes, detailed in the comments about
>>> individual
>>>   endpoints below.
>>>
>>> * Query paging
>>>
>>>   This feature adds a set of new HTTP query parameters that can be
used
>>> with most
>>>   of the query endpoints (`fact_names`, `facts`, `resources`,
`nodes`,
>>> `events`,
>>>   `reports`, `event-counts`) to allow paging through large result
sets
>>> over
>>>   multiple queries.  The available HTTP query parameters are:
>>>
>>>      * `limit`: an integer specifying the maximum number of results
to
>>>         return.
>>>      * `order-by`: a list of fields to sort by, in ascending or
>>> descending order.
>>>         The legal set of fields varies by endpoint; see the
documentation
>>> for
>>>         individual endpoints for more info.
>>>      * `offset`: an integer specifying the first result in the
result set
>>> that
>>>         should be returned.  This can be used in combination with
`limit`
>>>         and `order-by` to page through a result set over multiple
>>> queries.
>>>      * `include-total`: a boolean flag which, if set, will cause
the HTTP
>>> response
>>>        to contain an `X-Records` header indicating the total number
of
>>> results that are
>>>        available that match the query.  (Mainly useful in
combination
>>> with `limit`.)
>>>
>>> * New features available on `events` endpoint
>>>
>>>     * The `events` data now contains `file` and `line` fields. 
These
>>> indicate
>>>       the location in the manifests where the resource was
declared.
>>> They can
>>>       be used as input to an `events` query.
>>>     * Add new `configuration-version` field, which contains the
value
>>> that Puppet
>>>       supplied during the agent run.
>>>     * New `containing-class` field: if the resource is declared
inside of
>>> a
>>>       Puppet class, this field will contain the name of that class.
>>>     * New `containment-path` field: this field is an array showing
the
>>> full
>>>       path to the resource from the root of the catalog (contains
an
>>> ordered
>>>       list of names of the classes/types that the resource is
contained
>>> within).
>>>     * New queryable timestamp fields:
>>>         * `run-start-time`: the time (on the agent node) that the
run
>>> began
>>>         * `run-end-time`: the time (on the agent node) that the run
>>> completed
>>>         * `report-receive-time`: the time (on the puppetdb node)
that the
>>> report was received by PuppetDB
>>>     * Restrict results to only include events that occurred in the
latest
>>> report
>>>       for a given node: `["=",
"latest-report?", true]`
>>>
>>> * New `event-counts` endpoint
>>>
>>>     `v3` of the query API contains a new `event-counts` endpoint,
which
>>> can be
>>>     used to retrieve count data for an event query.  The basic
input to
>>> the
>>>     endpoint is an event query, just as you''d provide to
the `events`
>>> endpoint,
>>>     but rather than returning the actual events, this endpoint
returns
>>> counts
>>>     of `successes`, `failures`, `skips`, and `noops` for the events
that
>>> match
>>>     the query.  The counts may be aggregated on a per-resource,
>>> per-class,
>>>     or per-node basis.
>>>
>>> * New `aggregate-event-counts` endpoint
>>>
>>>   This endpoint is similar to the `event-counts` endpoint, but
rather
>>> than
>>>   aggregating the counts on a per-node, per-resource, or per-class
basis,
>>>   it returns aggregate counts across your entire population.
>>>
>>> * New `server-time` endpoint
>>>
>>>   This endpoint simply returns a timestamp indicating the current
time on
>>>   the PuppetDB server.  This can be used as input to time-based
queries
>>>   against timestamp fields that are populated by PuppetDB.
>>>
>>> * Minor changes to `resources` endpoint for `v3`
>>>
>>>   The `sourcefile` and `sourceline` fields have been renamed to
`file`
>>> and `line`,
>>>   for consistency with other parts of the API.
>>>
>>> * Minor changes relating to reports storage and query
>>>
>>>   * `store report` command has been bumped up to version `2`.
>>>   * Report data now includes a new `transaction-uuid` field; this
is
>>> generated
>>>     by Puppet (as of Puppet 3.3) and can be used to definitively
>>> correlate a report
>>>     with the catalog that was used for the run.  This field is
queryable
>>> on the
>>>     `reports` endpoint.
>>>   * Reports now support querying by the field `hash`; this allows
you to
>>> retrieve
>>>     data about a given report based on the report hash for an event
>>> returned
>>>     by the `events` endpoint.
>>>
>>> * Minor changes relating to catalog storage
>>>
>>>   * `store catalog` command has been bumped to version `3`.
>>>   * Catalog data now includes the new `transaction-uuid` field; see
notes
>>> above.
>>>
>>> Bug fixes:
>>>
>>> * PuppetDB report processor was truncating microseconds from report
>>> timestamps;
>>>   all timestamp fields should now retain full precision.
>>>
>>> * Record resource failures even if Puppet doesn''t generate
an event for
>>> them in the
>>>   report: in rare cases, Puppet will generate a report that
indicates a
>>> failure
>>>   on a resource but doesn''t actually provide a failure
event.  Prior to
>>> PuppetDB
>>>   1.5, the PuppetDB report processor was only checking for the
existence
>>> of
>>>   events, so these resources would not show up in the PuppetDB
report.
>>> This is
>>>   really a bug in Puppet (which should be fixed as of Puppet 3.3),
but
>>> the PuppetDB
>>>   report processor is now smart enough to detect this case and
synthesize
>>> a failure
>>>   event for the resource, so that the failure is at least visible
in the
>>> PuppetDB
>>>   report data.
>>>
>>> * Filter out the well-known "Skipped Schedule" events: in
versions of
>>> Puppet prior
>>>   to 3.3, every single agent report would include six events whose
status
>>> was
>>>   `skipped` and whose resource type was `Schedule`.  (The titles
were
>>> `never`,
>>>   `puppet`, `hourly`, `daily`, `weekly`, and `monthly`.)  These
events
>>> were not
>>>   generally useful and caused a great deal of pollution in the
PuppetDB
>>> database.
>>>   They are no longer generated as of Puppet 3.3, but for
compatibility
>>> with
>>>   older versions of Puppet, the report terminus in PuppetDB 1.5
will
>>> filter
>>>   these events out before storing the report in PuppetDB.
>>>
>>> * Log a message when a request is blocked due to the certificate
>>> whitelist:
>>>   prior to 1.5, when a query or command was rejected due to
PuppetDB''s
>>> certificate
>>>   whitelist configuration, there was no logging on the server that
could
>>> be used
>>>   to troubleshoot the cause of the rejection.  We now log a
message, in
>>> hopes of
>>>   making it easier for administrators to track down the cause of
>>> connectivity
>>>   issues in this scenario.
>>>
>>> * (#22122) Better log messages when puppetdb-ssl-setup is run
before
>>> Puppet
>>>   certificates are available.
>>>
>>> * (#22159) Fix a bug relating to anonymizing catalog edges in
exported
>>> PuppetDB
>>>   data.
>>>
>>> * (#22168) Add ability to configure maximum number of threads for
Jetty
>>> (having too
>>>   low of a value for this setting on systems with large numbers of
cores
>>> could
>>>   prevent Jetty from handling requests).
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
Groups
>>> "Puppet Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it,
send an
>>> email to puppet-dev+...@googlegroups.com.
>>> To post to this group, send email to puppe...@googlegroups.com.
>>>
>>> Visit this group at http://groups.google.com/group/puppet-dev.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
>> --
>> Thanks,
>> William
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-dev@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-dev.
> For more options, visit https://groups.google.com/groups/opt_out.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Sorry about that. Something went awry in the ship of 1.5.0. We''ve
updated the apt repos and 1.5.0 is now there for all of the debian and
ubuntu flavors. And as Ken said, thanks for letting us know!

On Tue, Oct 1, 2013 at 3:47 AM, Ken Barber <ken@puppetlabs.com>
wrote:
> Hmm ... thanks for letting us know.
>
> My humblest apologies, we''ll get the updates out for those distro
> releases ASAP. As Daniele mentioned, on apt.puppetlabs.com it seems
> only lucid is available now, the others releases are missing.
>
> ken.
>
> On Tue, Oct 1, 2013 at 9:56 AM, Daniele Sluijters
> <daniele.sluijters@gmail.com> wrote:
>> It''s not just the Precise packages that are missing. The
complete Debian
>> suite is missing too, squeeze, wheezy, jessy and sid.
>>
>>
>> On Tuesday, 1 October 2013 04:59:16 UTC+2, blkperl wrote:
>>>
>>> No packages for precise/raring? Its missing debs for 1.5.0. Lucid
seems
>>> fine
>>>
>>> Thanks,
>>> William
>>>
>>>
>>> On Mon, Sep 30, 2013 at 4:56 PM, Chris Price
<ch...@puppetlabs.com> wrote:
>>>>
>>>> PuppetDB 1.5.0 is now available for download!  This is a new
feature
>>>> release that contains a few bug-fixes as well.
>>>>
>>>> ============>>>> ## Downloads ##
>>>> ============>>>>
>>>> Available in native package format at:
>>>> http://yum.puppetlabs.com and http://apt.puppetlabs.com
>>>>
>>>> Puppet module:
>>>> http://forge.puppetlabs.com/puppetlabs/puppetdb
>>>>
>>>> Source (same license as Puppet):
http://github.com/puppetlabs/puppetdb/
>>>>
>>>> # Documentation (including how to install):
>>>> http://docs.puppetlabs.com/puppetdb/1.5
>>>>
>>>> # Issues can be filed at:
>>>> http://projects.puppetlabs.com/projects/puppetdb/issues
>>>>
>>>>
>>>> ===========================>>>> ##  PuppetDB 1.5.0
Release Notes  ##
>>>> ===========================>>>>
>>>> Notable features and improvements:
>>>>
>>>> * (#21520) Configuration for soft failure when PuppetDB is
unavailable
>>>>
>>>>   This feature adds a new option
''soft_write_failure'' to the puppetdb
>>>>   configuration.  If enabled the terminus behavior is changed
so that if
>>>> a
>>>>   command or write fails, instead of throwing an exception and
causing
>>>> the agent
>>>>   to stop it will simply log an error to the puppet master log.
>>>>
>>>> * New v3 query API
>>>>
>>>>   New `/v3` URLs are available for all query endpoints.  The
`reports`
>>>> and
>>>>   `events` endpoints, which were previously considered
`experimental`,
>>>> have
>>>>   been moved into `/v3`.  Most of the other endpoints are 100%
>>>> backwards-compatible
>>>>   with `/v2`, but now offer additional functionality.  There
are few
>>>> minor
>>>>   backwards-incompatible changes, detailed in the comments
about
>>>> individual
>>>>   endpoints below.
>>>>
>>>> * Query paging
>>>>
>>>>   This feature adds a set of new HTTP query parameters that can
be used
>>>> with most
>>>>   of the query endpoints (`fact_names`, `facts`, `resources`,
`nodes`,
>>>> `events`,
>>>>   `reports`, `event-counts`) to allow paging through large
result sets
>>>> over
>>>>   multiple queries.  The available HTTP query parameters are:
>>>>
>>>>      * `limit`: an integer specifying the maximum number of
results to
>>>>         return.
>>>>      * `order-by`: a list of fields to sort by, in ascending or
>>>> descending order.
>>>>         The legal set of fields varies by endpoint; see the
documentation
>>>> for
>>>>         individual endpoints for more info.
>>>>      * `offset`: an integer specifying the first result in the
result set
>>>> that
>>>>         should be returned.  This can be used in combination
with `limit`
>>>>         and `order-by` to page through a result set over
multiple
>>>> queries.
>>>>      * `include-total`: a boolean flag which, if set, will
cause the HTTP
>>>> response
>>>>        to contain an `X-Records` header indicating the total
number of
>>>> results that are
>>>>        available that match the query.  (Mainly useful in
combination
>>>> with `limit`.)
>>>>
>>>> * New features available on `events` endpoint
>>>>
>>>>     * The `events` data now contains `file` and `line` fields. 
These
>>>> indicate
>>>>       the location in the manifests where the resource was
declared.
>>>> They can
>>>>       be used as input to an `events` query.
>>>>     * Add new `configuration-version` field, which contains the
value
>>>> that Puppet
>>>>       supplied during the agent run.
>>>>     * New `containing-class` field: if the resource is declared
inside of
>>>> a
>>>>       Puppet class, this field will contain the name of that
class.
>>>>     * New `containment-path` field: this field is an array
showing the
>>>> full
>>>>       path to the resource from the root of the catalog
(contains an
>>>> ordered
>>>>       list of names of the classes/types that the resource is
contained
>>>> within).
>>>>     * New queryable timestamp fields:
>>>>         * `run-start-time`: the time (on the agent node) that
the run
>>>> began
>>>>         * `run-end-time`: the time (on the agent node) that the
run
>>>> completed
>>>>         * `report-receive-time`: the time (on the puppetdb
node) that the
>>>> report was received by PuppetDB
>>>>     * Restrict results to only include events that occurred in
the latest
>>>> report
>>>>       for a given node: `["=",
"latest-report?", true]`
>>>>
>>>> * New `event-counts` endpoint
>>>>
>>>>     `v3` of the query API contains a new `event-counts`
endpoint, which
>>>> can be
>>>>     used to retrieve count data for an event query.  The basic
input to
>>>> the
>>>>     endpoint is an event query, just as you''d provide
to the `events`
>>>> endpoint,
>>>>     but rather than returning the actual events, this endpoint
returns
>>>> counts
>>>>     of `successes`, `failures`, `skips`, and `noops` for the
events that
>>>> match
>>>>     the query.  The counts may be aggregated on a per-resource,
>>>> per-class,
>>>>     or per-node basis.
>>>>
>>>> * New `aggregate-event-counts` endpoint
>>>>
>>>>   This endpoint is similar to the `event-counts` endpoint, but
rather
>>>> than
>>>>   aggregating the counts on a per-node, per-resource, or
per-class basis,
>>>>   it returns aggregate counts across your entire population.
>>>>
>>>> * New `server-time` endpoint
>>>>
>>>>   This endpoint simply returns a timestamp indicating the
current time on
>>>>   the PuppetDB server.  This can be used as input to time-based
queries
>>>>   against timestamp fields that are populated by PuppetDB.
>>>>
>>>> * Minor changes to `resources` endpoint for `v3`
>>>>
>>>>   The `sourcefile` and `sourceline` fields have been renamed to
`file`
>>>> and `line`,
>>>>   for consistency with other parts of the API.
>>>>
>>>> * Minor changes relating to reports storage and query
>>>>
>>>>   * `store report` command has been bumped up to version `2`.
>>>>   * Report data now includes a new `transaction-uuid` field;
this is
>>>> generated
>>>>     by Puppet (as of Puppet 3.3) and can be used to
definitively
>>>> correlate a report
>>>>     with the catalog that was used for the run.  This field is
queryable
>>>> on the
>>>>     `reports` endpoint.
>>>>   * Reports now support querying by the field `hash`; this
allows you to
>>>> retrieve
>>>>     data about a given report based on the report hash for an
event
>>>> returned
>>>>     by the `events` endpoint.
>>>>
>>>> * Minor changes relating to catalog storage
>>>>
>>>>   * `store catalog` command has been bumped to version `3`.
>>>>   * Catalog data now includes the new `transaction-uuid` field;
see notes
>>>> above.
>>>>
>>>> Bug fixes:
>>>>
>>>> * PuppetDB report processor was truncating microseconds from
report
>>>> timestamps;
>>>>   all timestamp fields should now retain full precision.
>>>>
>>>> * Record resource failures even if Puppet doesn''t
generate an event for
>>>> them in the
>>>>   report: in rare cases, Puppet will generate a report that
indicates a
>>>> failure
>>>>   on a resource but doesn''t actually provide a failure
event.  Prior to
>>>> PuppetDB
>>>>   1.5, the PuppetDB report processor was only checking for the
existence
>>>> of
>>>>   events, so these resources would not show up in the PuppetDB
report.
>>>> This is
>>>>   really a bug in Puppet (which should be fixed as of Puppet
3.3), but
>>>> the PuppetDB
>>>>   report processor is now smart enough to detect this case and
synthesize
>>>> a failure
>>>>   event for the resource, so that the failure is at least
visible in the
>>>> PuppetDB
>>>>   report data.
>>>>
>>>> * Filter out the well-known "Skipped Schedule"
events: in versions of
>>>> Puppet prior
>>>>   to 3.3, every single agent report would include six events
whose status
>>>> was
>>>>   `skipped` and whose resource type was `Schedule`.  (The
titles were
>>>> `never`,
>>>>   `puppet`, `hourly`, `daily`, `weekly`, and `monthly`.)  These
events
>>>> were not
>>>>   generally useful and caused a great deal of pollution in the
PuppetDB
>>>> database.
>>>>   They are no longer generated as of Puppet 3.3, but for
compatibility
>>>> with
>>>>   older versions of Puppet, the report terminus in PuppetDB 1.5
will
>>>> filter
>>>>   these events out before storing the report in PuppetDB.
>>>>
>>>> * Log a message when a request is blocked due to the
certificate
>>>> whitelist:
>>>>   prior to 1.5, when a query or command was rejected due to
PuppetDB''s
>>>> certificate
>>>>   whitelist configuration, there was no logging on the server
that could
>>>> be used
>>>>   to troubleshoot the cause of the rejection.  We now log a
message, in
>>>> hopes of
>>>>   making it easier for administrators to track down the cause
of
>>>> connectivity
>>>>   issues in this scenario.
>>>>
>>>> * (#22122) Better log messages when puppetdb-ssl-setup is run
before
>>>> Puppet
>>>>   certificates are available.
>>>>
>>>> * (#22159) Fix a bug relating to anonymizing catalog edges in
exported
>>>> PuppetDB
>>>>   data.
>>>>
>>>> * (#22168) Add ability to configure maximum number of threads
for Jetty
>>>> (having too
>>>>   low of a value for this setting on systems with large numbers
of cores
>>>> could
>>>>   prevent Jetty from handling requests).
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the
Google Groups
>>>> "Puppet Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from
it, send an
>>>> email to puppet-dev+...@googlegroups.com.
>>>> To post to this group, send email to puppe...@googlegroups.com.
>>>>
>>>> Visit this group at http://groups.google.com/group/puppet-dev.
>>>> For more options, visit
https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> William
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an
>> email to puppet-dev+unsubscribe@googlegroups.com.
>> To post to this group, send email to puppet-dev@googlegroups.com.
>> Visit this group at http://groups.google.com/group/puppet-dev.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Announce" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-announce+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-announce@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-announce.
> For more options, visit https://groups.google.com/groups/opt_out.


-- 
Matthaus Owens
Release Manager, Puppet Labs

Join us at PuppetConf 2014, September 23-24 in San Francisco

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Someone kindly pointed out that the link to the docs in the original
release e-mail was pointing to an older version of the docs.  The correct
link is:

http://docs.puppetlabs.com/puppetdb/1.5



On Tue, Oct 1, 2013 at 10:11 AM, Matthaus Owens
<matthaus@puppetlabs.com>wrote:
> Sorry about that. Something went awry in the ship of 1.5.0. We''ve
> updated the apt repos and 1.5.0 is now there for all of the debian and
> ubuntu flavors. And as Ken said, thanks for letting us know!
>
> On Tue, Oct 1, 2013 at 3:47 AM, Ken Barber <ken@puppetlabs.com>
wrote:
> > Hmm ... thanks for letting us know.
> >
> > My humblest apologies, we''ll get the updates out for those
distro
> > releases ASAP. As Daniele mentioned, on apt.puppetlabs.com it seems
> > only lucid is available now, the others releases are missing.
> >
> > ken.
> >
> > On Tue, Oct 1, 2013 at 9:56 AM, Daniele Sluijters
> > <daniele.sluijters@gmail.com> wrote:
> >> It''s not just the Precise packages that are missing. The
complete Debian
> >> suite is missing too, squeeze, wheezy, jessy and sid.
> >>
> >>
> >> On Tuesday, 1 October 2013 04:59:16 UTC+2, blkperl wrote:
> >>>
> >>> No packages for precise/raring? Its missing debs for 1.5.0.
Lucid seems
> >>> fine
> >>>
> >>> Thanks,
> >>> William
> >>>
> >>>
> >>> On Mon, Sep 30, 2013 at 4:56 PM, Chris Price
<ch...@puppetlabs.com>
> wrote:
> >>>>
> >>>> PuppetDB 1.5.0 is now available for download!  This is a
new feature
> >>>> release that contains a few bug-fixes as well.
> >>>>
> >>>> ============> >>>> ## Downloads ##
> >>>> ============> >>>>
> >>>> Available in native package format at:
> >>>> http://yum.puppetlabs.com and http://apt.puppetlabs.com
> >>>>
> >>>> Puppet module:
> >>>> http://forge.puppetlabs.com/puppetlabs/puppetdb
> >>>>
> >>>> Source (same license as Puppet):
> http://github.com/puppetlabs/puppetdb/
> >>>>
> >>>> # Documentation (including how to install):
> >>>> http://docs.puppetlabs.com/puppetdb/1.5
> >>>>
> >>>> # Issues can be filed at:
> >>>> http://projects.puppetlabs.com/projects/puppetdb/issues
> >>>>
> >>>>
> >>>> ===========================> >>>> ## 
PuppetDB 1.5.0 Release Notes  ##
> >>>> ===========================> >>>>
> >>>> Notable features and improvements:
> >>>>
> >>>> * (#21520) Configuration for soft failure when PuppetDB is
unavailable
> >>>>
> >>>>   This feature adds a new option
''soft_write_failure'' to the puppetdb
> >>>>   configuration.  If enabled the terminus behavior is
changed so that
> if
> >>>> a
> >>>>   command or write fails, instead of throwing an exception
and causing
> >>>> the agent
> >>>>   to stop it will simply log an error to the puppet master
log.
> >>>>
> >>>> * New v3 query API
> >>>>
> >>>>   New `/v3` URLs are available for all query endpoints. 
The `reports`
> >>>> and
> >>>>   `events` endpoints, which were previously considered
`experimental`,
> >>>> have
> >>>>   been moved into `/v3`.  Most of the other endpoints are
100%
> >>>> backwards-compatible
> >>>>   with `/v2`, but now offer additional functionality. 
There are few
> >>>> minor
> >>>>   backwards-incompatible changes, detailed in the comments
about
> >>>> individual
> >>>>   endpoints below.
> >>>>
> >>>> * Query paging
> >>>>
> >>>>   This feature adds a set of new HTTP query parameters
that can be
> used
> >>>> with most
> >>>>   of the query endpoints (`fact_names`, `facts`,
`resources`, `nodes`,
> >>>> `events`,
> >>>>   `reports`, `event-counts`) to allow paging through large
result sets
> >>>> over
> >>>>   multiple queries.  The available HTTP query parameters
are:
> >>>>
> >>>>      * `limit`: an integer specifying the maximum number
of results to
> >>>>         return.
> >>>>      * `order-by`: a list of fields to sort by, in
ascending or
> >>>> descending order.
> >>>>         The legal set of fields varies by endpoint; see
the
> documentation
> >>>> for
> >>>>         individual endpoints for more info.
> >>>>      * `offset`: an integer specifying the first result in
the result
> set
> >>>> that
> >>>>         should be returned.  This can be used in
combination with
> `limit`
> >>>>         and `order-by` to page through a result set over
multiple
> >>>> queries.
> >>>>      * `include-total`: a boolean flag which, if set, will
cause the
> HTTP
> >>>> response
> >>>>        to contain an `X-Records` header indicating the
total number of
> >>>> results that are
> >>>>        available that match the query.  (Mainly useful in
combination
> >>>> with `limit`.)
> >>>>
> >>>> * New features available on `events` endpoint
> >>>>
> >>>>     * The `events` data now contains `file` and `line`
fields.  These
> >>>> indicate
> >>>>       the location in the manifests where the resource was
declared.
> >>>> They can
> >>>>       be used as input to an `events` query.
> >>>>     * Add new `configuration-version` field, which
contains the value
> >>>> that Puppet
> >>>>       supplied during the agent run.
> >>>>     * New `containing-class` field: if the resource is
declared
> inside of
> >>>> a
> >>>>       Puppet class, this field will contain the name of
that class.
> >>>>     * New `containment-path` field: this field is an array
showing the
> >>>> full
> >>>>       path to the resource from the root of the catalog
(contains an
> >>>> ordered
> >>>>       list of names of the classes/types that the resource
is
> contained
> >>>> within).
> >>>>     * New queryable timestamp fields:
> >>>>         * `run-start-time`: the time (on the agent node)
that the run
> >>>> began
> >>>>         * `run-end-time`: the time (on the agent node)
that the run
> >>>> completed
> >>>>         * `report-receive-time`: the time (on the puppetdb
node) that
> the
> >>>> report was received by PuppetDB
> >>>>     * Restrict results to only include events that
occurred in the
> latest
> >>>> report
> >>>>       for a given node: `["=",
"latest-report?", true]`
> >>>>
> >>>> * New `event-counts` endpoint
> >>>>
> >>>>     `v3` of the query API contains a new `event-counts`
endpoint,
> which
> >>>> can be
> >>>>     used to retrieve count data for an event query.  The
basic input
> to
> >>>> the
> >>>>     endpoint is an event query, just as you''d
provide to the `events`
> >>>> endpoint,
> >>>>     but rather than returning the actual events, this
endpoint returns
> >>>> counts
> >>>>     of `successes`, `failures`, `skips`, and `noops` for
the events
> that
> >>>> match
> >>>>     the query.  The counts may be aggregated on a
per-resource,
> >>>> per-class,
> >>>>     or per-node basis.
> >>>>
> >>>> * New `aggregate-event-counts` endpoint
> >>>>
> >>>>   This endpoint is similar to the `event-counts` endpoint,
but rather
> >>>> than
> >>>>   aggregating the counts on a per-node, per-resource, or
per-class
> basis,
> >>>>   it returns aggregate counts across your entire
population.
> >>>>
> >>>> * New `server-time` endpoint
> >>>>
> >>>>   This endpoint simply returns a timestamp indicating the
current
> time on
> >>>>   the PuppetDB server.  This can be used as input to
time-based
> queries
> >>>>   against timestamp fields that are populated by PuppetDB.
> >>>>
> >>>> * Minor changes to `resources` endpoint for `v3`
> >>>>
> >>>>   The `sourcefile` and `sourceline` fields have been
renamed to `file`
> >>>> and `line`,
> >>>>   for consistency with other parts of the API.
> >>>>
> >>>> * Minor changes relating to reports storage and query
> >>>>
> >>>>   * `store report` command has been bumped up to version
`2`.
> >>>>   * Report data now includes a new `transaction-uuid`
field; this is
> >>>> generated
> >>>>     by Puppet (as of Puppet 3.3) and can be used to
definitively
> >>>> correlate a report
> >>>>     with the catalog that was used for the run.  This
field is
> queryable
> >>>> on the
> >>>>     `reports` endpoint.
> >>>>   * Reports now support querying by the field `hash`; this
allows you
> to
> >>>> retrieve
> >>>>     data about a given report based on the report hash for
an event
> >>>> returned
> >>>>     by the `events` endpoint.
> >>>>
> >>>> * Minor changes relating to catalog storage
> >>>>
> >>>>   * `store catalog` command has been bumped to version
`3`.
> >>>>   * Catalog data now includes the new `transaction-uuid`
field; see
> notes
> >>>> above.
> >>>>
> >>>> Bug fixes:
> >>>>
> >>>> * PuppetDB report processor was truncating microseconds
from report
> >>>> timestamps;
> >>>>   all timestamp fields should now retain full precision.
> >>>>
> >>>> * Record resource failures even if Puppet doesn''t
generate an event
> for
> >>>> them in the
> >>>>   report: in rare cases, Puppet will generate a report
that indicates
> a
> >>>> failure
> >>>>   on a resource but doesn''t actually provide a
failure event.  Prior
> to
> >>>> PuppetDB
> >>>>   1.5, the PuppetDB report processor was only checking for
the
> existence
> >>>> of
> >>>>   events, so these resources would not show up in the
PuppetDB report.
> >>>> This is
> >>>>   really a bug in Puppet (which should be fixed as of
Puppet 3.3), but
> >>>> the PuppetDB
> >>>>   report processor is now smart enough to detect this case
and
> synthesize
> >>>> a failure
> >>>>   event for the resource, so that the failure is at least
visible in
> the
> >>>> PuppetDB
> >>>>   report data.
> >>>>
> >>>> * Filter out the well-known "Skipped Schedule"
events: in versions of
> >>>> Puppet prior
> >>>>   to 3.3, every single agent report would include six
events whose
> status
> >>>> was
> >>>>   `skipped` and whose resource type was `Schedule`.  (The
titles were
> >>>> `never`,
> >>>>   `puppet`, `hourly`, `daily`, `weekly`, and `monthly`.) 
These events
> >>>> were not
> >>>>   generally useful and caused a great deal of pollution in
the
> PuppetDB
> >>>> database.
> >>>>   They are no longer generated as of Puppet 3.3, but for
compatibility
> >>>> with
> >>>>   older versions of Puppet, the report terminus in
PuppetDB 1.5 will
> >>>> filter
> >>>>   these events out before storing the report in PuppetDB.
> >>>>
> >>>> * Log a message when a request is blocked due to the
certificate
> >>>> whitelist:
> >>>>   prior to 1.5, when a query or command was rejected due
to PuppetDB''s
> >>>> certificate
> >>>>   whitelist configuration, there was no logging on the
server that
> could
> >>>> be used
> >>>>   to troubleshoot the cause of the rejection.  We now log
a message,
> in
> >>>> hopes of
> >>>>   making it easier for administrators to track down the
cause of
> >>>> connectivity
> >>>>   issues in this scenario.
> >>>>
> >>>> * (#22122) Better log messages when puppetdb-ssl-setup is
run before
> >>>> Puppet
> >>>>   certificates are available.
> >>>>
> >>>> * (#22159) Fix a bug relating to anonymizing catalog edges
in exported
> >>>> PuppetDB
> >>>>   data.
> >>>>
> >>>> * (#22168) Add ability to configure maximum number of
threads for
> Jetty
> >>>> (having too
> >>>>   low of a value for this setting on systems with large
numbers of
> cores
> >>>> could
> >>>>   prevent Jetty from handling requests).
> >>>>
> >>>>
> >>>> --
> >>>> You received this message because you are subscribed to
the Google
> Groups
> >>>> "Puppet Developers" group.
> >>>> To unsubscribe from this group and stop receiving emails
from it,
> send an
> >>>> email to puppet-dev+...@googlegroups.com.
> >>>> To post to this group, send email to
puppe...@googlegroups.com.
> >>>>
> >>>> Visit this group at
http://groups.google.com/group/puppet-dev.
> >>>> For more options, visit
https://groups.google.com/groups/opt_out.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Thanks,
> >>> William
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Puppet Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it,
send
> an
> >> email to puppet-dev+unsubscribe@googlegroups.com.
> >> To post to this group, send email to puppet-dev@googlegroups.com.
> >> Visit this group at http://groups.google.com/group/puppet-dev.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Puppet Announce" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to puppet-announce+unsubscribe@googlegroups.com.
> > To post to this group, send email to puppet-announce@googlegroups.com.
> > Visit this group at http://groups.google.com/group/puppet-announce.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> Matthaus Owens
> Release Manager, Puppet Labs
>
> Join us at PuppetConf 2014, September 23-24 in San Francisco
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Announce" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-announce+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-announce@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-announce.
> For more options, visit https://groups.google.com/groups/opt_out.
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.

W dniu wtorek, 1 października 2013 19:11:40 UTC+2 użytkownik Matthaus 
Litteken napisał:
>
> Sorry about that. Something went awry in the ship of 1.5.0. We''ve 
> updated the apt repos and 1.5.0 is now there for all of the debian and 
> ubuntu flavors. And as Ken said, thanks for letting us know! 
>
it seems that rsync is out of the loop too :(

-bash-3.2$ GET -deS 
http://yum.puppetlabs.com/el/5/products/x86_64/puppetdb-1.5.0-1.el5.noarch.rpm
GET 
http://yum.puppetlabs.com/el/5/products/x86_64/puppetdb-1.5.0-1.el5.noarch.rpm 
--> 200 OK
Connection: close
Date: Wed, 02 Oct 2013 15:56:26 GMT
Accept-Ranges: bytes
ETag: "240711-139ddf8-4e7a274f87200"
Server: Apache
Content-Length: 20569592
Content-Type: application/x-redhat-package-manager
Last-Modified: Mon, 30 Sep 2013 23:47:20 GMT
Client-Date: Wed, 02 Oct 2013 15:57:04 GMT
Client-Peer: 198.58.114.168:80
Client-Response-Num: 1
X-Frame-Options: SAMEORIGIN

-bash-3.2$ rsync 
rsync://burji.puppetlabs.com/packages/yum/el/5/products/x86_64/puppetdb-1.5.0-1.el5.noarch.rpm
rsync: link_stat 
"/yum/el/5/products/x86_64/puppetdb-1.5.0-1.el5.noarch.rpm" (in
packages)
failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) 
(code 23) at main.c(1508) [Receiver=3.0.7] 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

burji is a hostname for a machine that is no longer in use. I would
rsync using the yum.puppetlabs.com hostname. The following works for
me:

rsync
rsync://yum.puppetlabs.com/packages/yum/el/5/products/x86_64/puppetdb-1.5.0-1.el5.noarch.rpm
-rw-r--r--    20569592 2013/09/30 16:47:20 puppetdb-1.5.0-1.el5.noarch.rpm

Hope that helps.

On Wed, Oct 2, 2013 at 9:03 AM, asq <asquelt@gmail.com>
wrote:
> W dniu wtorek, 1 października 2013 19:11:40 UTC+2 użytkownik Matthaus
> Litteken napisał:
>>
>> Sorry about that. Something went awry in the ship of 1.5.0.
We''ve
>> updated the apt repos and 1.5.0 is now there for all of the debian and
>> ubuntu flavors. And as Ken said, thanks for letting us know!
>
>
> it seems that rsync is out of the loop too :(
>
> -bash-3.2$ GET -deS
>
http://yum.puppetlabs.com/el/5/products/x86_64/puppetdb-1.5.0-1.el5.noarch.rpm
> GET
>
http://yum.puppetlabs.com/el/5/products/x86_64/puppetdb-1.5.0-1.el5.noarch.rpm
> --> 200 OK
> Connection: close
> Date: Wed, 02 Oct 2013 15:56:26 GMT
> Accept-Ranges: bytes
> ETag: "240711-139ddf8-4e7a274f87200"
> Server: Apache
> Content-Length: 20569592
> Content-Type: application/x-redhat-package-manager
> Last-Modified: Mon, 30 Sep 2013 23:47:20 GMT
> Client-Date: Wed, 02 Oct 2013 15:57:04 GMT
> Client-Peer: 198.58.114.168:80
> Client-Response-Num: 1
> X-Frame-Options: SAMEORIGIN
>
> -bash-3.2$ rsync
>
rsync://burji.puppetlabs.com/packages/yum/el/5/products/x86_64/puppetdb-1.5.0-1.el5.noarch.rpm
> rsync: link_stat
"/yum/el/5/products/x86_64/puppetdb-1.5.0-1.el5.noarch.rpm"
> (in packages) failed: No such file or directory (2)
> rsync error: some files/attrs were not transferred (see previous errors)
> (code 23) at main.c(1508) [Receiver=3.0.7]
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
>
> For more options, visit https://groups.google.com/groups/opt_out.


-- 
Matthaus Owens
Release Manager, Puppet Labs

Join us at PuppetConf 2014, September 23-24 in San Francisco

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.