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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
