Announce: PuppetDB 0.10.0 Available

[Matthaus Litteken]

PuppetDB 0.10.0 is the fourth beta release on the road to 1.0. Changes
include new features and bug fixes. For details on changes
in this release, please see the release notes below.

# Downloads

Available in native package format at

http://yum.puppetlabs.com

http://apt.puppetlabs.com

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

Available for use with Puppet Enterprise 2.5.1 and later at

http://yum-enterprise.puppetlabs.com/ and http://apt-enterprise.puppetlabs.com/

# Documentation (including how to install): http://docs.puppetlabs.com/puppetdb

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

# Upgrading

1. On your puppetdb server, stop the puppetdb daemon
2. On your puppetmaster(s), stop the puppetmaster daemon
3. On your puppetdb server, install the new puppetdb package
4. On your puppetdb server, start the puppetdb daemon
5. On your puppetmaster(s), install the new puppetdb-terminus package
6. On your puppetmaster(s), start the puppetmaster daemon

0.10.0 Change Log
=========

Many thanks to the following people who contributed patches to this
release:

* Deepak Giridharagopal
* Nick Lewis
* Matthaus Litteken
* Moses Mendoza
* Chris Price

Notable features:

* Auto-deactivation of stale nodes

There is a new, optional setting you can add to the `[database]`
section of your configuration: `node-ttl-days`, which defines how
long, in days, a node can continue without seeing new activity (new
catalogs, new facts, etc) before it's automatically deactivated
during a garbage-collection run.

The default behavior, if that config setting is ommitted, is the
same as in previous releases: no automatic deactivation of anything.

This feature is useful for those who have a non-trivial amount of
volatility in the lifecycles of their nodes, such as those who
regularly bring up nodes in a cloud environment and tear them down
shortly thereafter.

* (#15696) Limit the number of results returned from a resource query

For sites with tens or even hundreds of thousands of resources, an
errant query could result in PuppetDB attempting to pull in a large
number of resources and parameters into memory before serializing
them over the wire. This can potentially trigger out-of-memory
conditions.

There is a new, optional setting you can add to the `[database]`
section of your configuration: `resource-query-limit`, which denotes
the maximum number of resources returnable via a resource query. If
the supplied query results in more than the indicated number of
resources, we return an HTTP 500.

The default behavior is to limit resource queries to 20,000
resources.

* (#15696) Slow query logging

There is a new, optional setting you can add to the `[database]`
section of your configuration: `log-slow-statements`, which denotes
how many seconds a database query can take before the query is
logged at WARN level.

The default behavior is to log queries that take more than 10
seconds.

* Add support for a --debug flag, and a debug-oriented startup script

This commit adds support for a new command-line flag: --debug. For
now, this flag only affects logging; it forces a console logger and
ensures that the log level is set to DEBUG. The option is also
added to the main config hash so that it can potentially be used for
other purposes in the future.

This commit also adds a shell script, `puppetdb-foreground`, which
can be used to launch the services from the command line. This
script will be packaged (in /usr/sbin) along with the
puppetdb-ssl-setup script, and may be useful in helping users
troubleshoot problems on their systems (especially problems with
daemon startup).

Notable fixes:

* Update CONTRIBUTING.md to better reflect reality

The process previously described in CONTRIBUTING.md was largely
vestigial; we've now updated that documentation to reflect the
actual, current contribution process.

* Proper handling of composite namevars

Normally, as part of converting a catalog to the PuppetDB wire
format, we ensure that every resource has its namevar as one of its
aliases. This allows us to handle edges that refer to said resource
using its namevar instead of its title.

However, Puppet implements `#namevar` for resources with composite
namevars in a strange way, only returning part of the composite
name. This can result in bugs in the generated catalog, where we
may have 2 resources with the same alias (because `#namevar` returns
the same thing for both of them).

Because resources with composite namevars can't be referred to by
anything other than their title when declaring relationships,
there's no real point to adding their aliases in anyways. So now we
don't bother.

* Fix deb packaging so that the puppetdb service is restarted during
upgrades

Prior to this commit, when you ran a debian package upgrade, the
puppetdb service would be stopped but would not be restarted.

* (#1406) Add curl-based query examples to docs

The repo now contains examples of querying PuppetDB via curl over
both HTTP and HTTPS.

* Document how to configure PuppetDB to work with "puppet apply"

There are some extra steps necessary to get PuppetDB working
properly with Puppet apply, and there are limitations
thereafter. The repo now contains documentation around what those
limitations are, and what additional configuration is necessary.

* Upgrade testing during acceptance test runs

We now automatically test upgrades from the last published version
of PuppetDB to the currently-under-test version.

* (#15281) Add postgres support to acceptance testing

Our acceptance tests now regularly run against both the embedded
database and PostgreSQL, automatically, on every commit.

* (#15378) Improve behavior of acceptance tests in single-node
environment

We have some acceptance tests that require multiple nodes in order
to execute successfully (mostly around exporting / collecting
resources). If you tried to run them in a single-node environment,
they would give a weird ruby error about 'nil' not defining a
certain method. Now, they will be skipped if you are running without
more than one host in your acceptance test-bed.

* Spec tests now work against Puppet master branch

We now regularly, and automatically, run PuppetDB spec tests against
Puppet's master branch.

* Acceptance testing for RPM-based systems

Previously we were running all of our acceptance tests solely
against Debain systems. We now run them all, automatically upon each
commit, against RedHat machines as well.

* Add new `rake version` task

Does what it says on the tin.