ANNOUNCE: Puppet 2.6.0 - Release Candidate 2 available!
James Turnbull
eleventy times better RC2 release.
The 2.6.0 release is a major feature release and includes a huge variety
of new features, fixes, updates and enhancements. These include the
complete cut-over from XMLRPC to the REST API, numerous language
enhancements, a complete rewrite of the events and reporting system, an
internal Ruby DSL, a single binary, Windows support, a new HTTP report
processor, and a
myriad of other enhancements.
As a result of the bucket-load of new features and enhancements we also
need lots of help testing it. Please run up the release candidate in
your test environment or using VMs and test it as extensively as
possible.
We've include release notes below that you can also see at:
http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
The release candidate is available for download at:
http://puppetlabs.com/downloads/puppet/puppet-2.6.0rc2.tar.gz
Please note that all final releases of Puppet are signed with the
Puppet Labs key (we'll sign the production release with the new,
improved Puppet Labs key).
See the Verifying Puppet Download section at
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
Please test this release candidate and report feedback via the
Puppet Labs Redmine site:
http://projects.puppetlabs.com
Please select an affected version of 2.6.0rc2.
RELEASE NOTES
Language
Support for parameterised classes
The 2.6.0 release provides an extension to the existing class syntax to
allow parameters to be passed to classes. This brings classes more in
line with definitions, with the significant difference that definitions
have multiple instances whilst classes remain singletons.
To create a class with parameters you can now specify:
class apache($version) {
... class contents ...
}
Classes with parameters are NOT added using the include function but
rather the resulting class can then be included more like a definition:
node webserver {
class { apache: version => "1.3.13" }
}
Like definitions, you can also specify default parameter values in your
class like so:
class apache($version="1.3.13",$home="/var/www") {
... class contents ...
}
New relationship syntax
You can now specify relationships directly in the language:
File[/foo] -> Service[bar]
Specifies a normal dependency while:
File[/foo] ~> Service[bar]
Specifies a subscription.
You can also do relationship chaining, specifying multiple relationships
on a single line:
File[/foo] -> Package[baz] -> Service[bar]
Note that while it�s confusing, you don�t have to have all of the arrows
be the same direction:
File[/foo] -> Service[bar] <~ Package[baz]
This can provide some succinctness at the cost of readability.
You can also specify full resources, rather than just resource references:
file { "/foo": ensure => present } -> package { bar: ensure => installed }
But wait! There�s more! You can also specify a subscription on either
side of the relationship marker:
yumrepo { foo: .... }
package { bar: provider => yum, ... }
Yumrepo <| |> -> Package <| provider == yum |>
This, finally, provides easy many to many relationships in Puppet, but
it also opens the door to massive dependency cycles. This last feature
is a very powerful stick, and you can considerably hurt yourself with it.
Run Stages
Run Stages are a way for you to provide coarse-grained ordering in your
manifests without having to specify relationships to every resource you
want in a given order. It�s most useful for setup work that needs to be
done before the vast majority of your catalog even works � things like
configuring yum repositories so your package installs work.
Run Stages are currently (intentionally) a bit limited � you can only
put entire classes into a run stage, you can�t put individual resources
there.
There�s a main stage that resources all exist in by default; if you
don�t use run stages, everything�s in this, but it doesn�t matter to
you. You can define new stages via the new stage resource type:
stage { pre: before => Stage[main] }
Here we�ve used the before metaparameter but you could also use after,
require, etc to establish the necessary relationships between stages.
Now you just specify that your class belongs in your new run stage:
class yum { ... }
class redhat {
...
class { yum: stage => pre }
}
This will make sure that all of the resources in the yum are applied
before the main stage is applied.
Note that we�re using the new parameterized classes here � this is
necessary because of the class-level limitations of Run Stages. These
limitations are present because of the complication of trying to
untangle resource dependencies across stage boundaries if we allowed
arbitrary resources to specify stages.
On a related note, if you specify a stage for a given class, you should
specify as few as possible explicit relationships to or from that class.
Otherwise you risk a greater chance of dependency cycles.
This can all be visualized relatively easily using the �graph option to
puppetd and opening the graphs in OmniGraffle or GraphViz.
Specifying the ordering of Run Stages also works much better when
specified using the new relationship syntax, too:
stage { [pre, post]: }
Stage[pre] -> Stage[main] -> Stage[post]
This way it�s very easy to see at a glance exactly how the stages are
ordered.
Support for hashes in the DSL
This brings a new container syntax to the Puppet DSL: hashes.
Hashes are defined like Ruby Hashes:
{ key1 => val1, ... }
The Hash keys are strings but hash values can be any possible right
values admitted in Puppet DSL (i.e. a function call or a variable)
Currently it is possible:
* to assign hashes to a variable
$myhash = { key1 => "myval", key2 => $b }
* to access hash members (recursively) from a variable containing a hash
(works for array too):
$myhash = { key => { subkey => "b" }}
notice($myhash[key][subkey]]
* to use hash member access as resource title
* to use hash in default definition parameter or resource parameter if
the type supports it (known for the moment).
It is not possible to use an hash as a resource title. This might be
possible once we support compound resource title.
Support for an elsif syntax
Allows use of an elsif construct:
if $server == 'mongrel' {
include mongrel
} elsif $server == 'nginx' {
include nginx
} else {
include thin
}
Case and Selectors now support undef
The case and selector statements now support the undef syntax (see #2818).
Pure Ruby Manifests
Puppet now supports pure Ruby manifests as equivalent to Puppet�s custom
language. That is, you can now have Ruby programs along side your Puppet
manifests. As is our custom, it�s a limited first version, but it covers
most of the specification functionality of the current language. For
instance, here�s a simple ssh class:
hostclass :ssh do
package "ssh", :ensure => :present
file "/etc/ssh/sshd_config", :source => "puppet:///ssh/sshd_config",
:require => "Package[ssh]"
service :sshd, :ensure => :running, :require =>
"File[/etc/ssh/sshd_config]"
end
Similar to the �hostclass� construct here, you can specify defined
resource types:
define "apache::vhost", :ip, :docroot, :modperl => false do
file "/etc/apache2/sites-enabled/#{@name}.conf", :content =>
template("apache/vhost.erb")
end
As you can see from this code, the parameters for the resources become
instance variables inside of the defined resource types (and classes,
now that we support parameterized classes).
We can do nodes, too:
node �mynode� do
include �apache�
end
Ruby has become a first-class citizen alongside the existing external
DSL. That means anywhere you can put a manifest, you should be able to
put Ruby code and have it behave equivalently. So, the �ssh� class above
could be put into �$modules/ssh/manifests/init.rb�, the apache vhost
type should be placed in �$modules/apache/manifests/vhost.rb�, and the
node should probably be in your �site.pp� file.
You can also apply Ruby manifests directly with puppet:
puppet -e mystuff.rb
Note that the Ruby support does not yet cover all of the functionality
in Puppet�s language. For instance, there is not yet support for
overrides or defaults, nor for resource collections. Virtual and
exported resources are done using a separate method:
virtual file("/my/file", :content => "something")
All of the standard functions are also pulled into Ruby and should work
fine � e.g., �include�, �template�, and �require�.
Stored Configuration
Support is now added for using Oracle databases as a back-end for your
stored configuration.
Facts
There are three new facts available in manifests:
$clientcert � the name of the client certificate
$module_name � the name of the current module (see #1545)
$caller_module_name � the name of the calling module (see #1545)
In addition all puppet.conf configuration items are now available as
facts in your manifests. These can be accessed using the structure:
$settings::setting_name
Where setting_name is the name of the configuration option you�d like to
retrieve.
Types and Providers
A new provider for pkg has been added to support Solaris and OpenSolaris
(pkgadd).
A new package provider has been added to support AIX package management.
The augeas type has added the �incl� and �lens� parameters. These
parameters allow loading a file anywhere on the filesystem; using them
also greatly speeds up processing the resource.
Binaries and Configuration
Single Binary
Puppet is now available as a single binary with sub-arguments for the
functions previously provided by the seperate binaries (the existing
binaries remain for backwards compatibility). This includes renaming
several Puppet functions to better fit an overall model.
List of binary changes
puppetmasterd �> puppet master
puppetd �> puppet agent
puppet �> puppet apply
puppetca �> puppet cert
ralsh �> puppet resource
puppetrun �> puppet kick
puppetqd �> puppet queue
filebucket �> puppet filebucket
puppetdoc �> puppet doc
pi �> puppet describe
This also results in a change in the puppet.conf configuration file.
The sections, previously things like [puppetd], now should be renamed to
match the new binary names. So [puppetd] becomes [agent]. You will be
prompted to do this when you start Puppet with a log message for each
section that needs to be renamed. This is merely a warning - existing
configuration file will work unchanged.
New options
A new option is available, ca_name, to specify the name to use for the
Certificate Authority certificate. It defaults to the value of the
certname option (see http://projects.reductivelabs.com/issues/1507).
A new option, dbconnections, is now available that specifies a limit for
the number of database connections made to remote databases (postgreSQL,
MySQL).
A new option, dbport, is now available that specifies the database port
for remote database connections.
There�s also a new option/feature that lets the puppet client use HTTP
compression (�http_compression):
Allow http compression in REST communication with the master. This
setting might improve performance for agent �> master communications
over slow WANs. Your puppetmaster needs to support compression (usually
by activating some settings in a reverse-proxy in front of the
puppetmaster, which rules out webrick).
It is harmless to activate this settings if your master doesn�t support
compression, but if it supports it, this setting might reduce on
high-speed LANs.
Binary changes
The puppetd (or puppet agent) binary now supports the
--detailed-exitcodes option available in the puppet binary.
Certificates cleaned with puppetca (or puppet cert) are now also revoked.
The puppetca (puppet cert) and puppetd (puppet agent) binaries now have
support for certificate fingerprinting and support for specifying digest
algorithms. To display the fingerprint of a client certificate use:
$ puppetd --fingerprint
or
$ puppet agent --fingerprint
To specify a particular digest algorithm use --digest DIGESTNAME.
To fingerprint a certificate with puppetca use:
$ puppetca --fingerprint host.example.com
or
$ puppet cert --fingerprint host.example.com
Also supported is the --digest option.
The puppetdoc binary now documents inheritance between nodes, shows
classes added via the require function and resources added via the
realize function.
Functions
The regsubst function now takes arrays as input (see #2491).
Reports
There is a new report type called http. If you specify:
reports = http
Then the new report processor will make a HTTP POST of the report in
YAML format to a specified URL. By default this URL is the report import
URL for a local Puppet Dashboard installation. You can override this
with the new reporturl setting.
reports = http
reporturl = http://yoururl/post/
CHANGELOG since RC1
fa74020 [#4209] catalog.resources should return resources
f5f9a38 Fix for #4210 -- missing require in CA
1c3e844 Minimal fix for #4205 -- incorrect Import loop messages
99d8323 Fix #4206 - import "path/*" tries to import files twice
a2115af Alt fix for #4207 -- serialize environments as their names
fe4dcd8 [#4208] Missing parameter breaks multithread compilation
Regards
James Turnbull
-- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571
Rudy Gevaert
On Jul 12, 8:09 am, James Turnbull <ja...@puppetlabs.com> wrote:
> Welcome back again to the Puppet release cycle with the long-awaited
> eleventy times better RC2 release.
Any chance of providing debian packages for rc2? Or pointing me to an
url where I can download the source with the Debian directory in?
Thanks!
Rudy
James Turnbull
We don't generally package downstream - except gems - ourselves.
You can find the Debian packaging stuff at:
http://git.debian.org/?p=pkg-puppet/puppet.git
Jasper Poppe
binary syntax, etc.) but it seems to work fine (package wise).
Here are the instructions:
====== Build Puppet 2.6 RC2 Debian Packages ======
Prerequisites
apt-get install build-essential devscripts
Install needed dependencies
apt-get build-dep puppet
Prepare directory structure
cd
mkdir -p build/puppet
cd build/puppet
Download the needed Debian source files from the latest version, and
latest version of puppet
wget http://ftp.de.debian.org/debian/pool/main/p/puppet/puppet_0.25.5-1.debian.tar.gz
wget http://puppetlabs.com/downloads/puppet/puppet-2.6.0rc2.tar.gz
Rename the Puppet tar file to Debian style
mv puppet-2.6.0rc2.tar.gz puppet_2.6.0rc2.orig.tar.gz
Extract the tar files
tar zxvf puppet_2.6.0rc2.orig.tar.gz
tar zxvf puppet_0.25.5-1.debian.tar.gz -C puppet-2.6.0rc2
Update the changelog
cd puppet-2.6.0rc2
dch -v 2.6.0rc2-1
Remove the old patches
mv debian/patches /tmp
Build the Debian packages
dpkg-buildpackage
Jasper Poppe
ssh::knownhosts' will generate the following error on the client:
err: Could not retrieve catalog from remote server: execution expired
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
I have this with all sub classes and also when you call a define which
is in a class, for example:
apt::define_key {
foo => bar;
}
Peter Meier
Hash: SHA1
> Is it me or do subclasses work differently? For example: 'include
> ssh::knownhosts' will generate the following error on the client:
>
> err: Could not retrieve catalog from remote server: execution expired
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
this seems to be more a timeout issue, but anyway:
> I have this with all sub classes and also when you call a define which
> is in a class, for example:
> apt::define_key {
> foo => bar;
> }
can you give a broader picture? and what also would be interesting is
what the master is telling you, maybe also run it with --debug --trace.
cheers pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkw8rz4ACgkQbwltcAfKi3+LfgCdEJe/Y/yPqDmG9NcHRhM2R9Vx
rP8AoIAlJE14aRVY8xgZ9NYkLEstZBy9
=s62y
-----END PGP SIGNATURE-----
Todd Zullinger
> Welcome back again to the Puppet release cycle with the long-awaited
> eleventy times better RC2 release.
>
> The 2.6.0 release is a major feature release and includes a huge
> variety of new features, fixes, updates and enhancements. These
> include the complete cut-over from XMLRPC to the REST API, numerous
> language enhancements, a complete rewrite of the events and
> reporting system, an internal Ruby DSL, a single binary, Windows
> support, a new HTTP report processor, and a myriad of other
> enhancements.
>
> As a result of the bucket-load of new features and enhancements we
> also need lots of help testing it. Please run up the release
> candidate in your test environment or using VMs and test it as
> extensively as possible.
For thoae using Fedora or RHEL/CentOS, I've updated the yum repos at:
http://tmz.fedorapeople.org/repo/puppet/
Packages for EL 4 - 6 and Fedora 12 - 13 are available for testing.
Add the puppet.repo file from either the epel or fedora directories to
/etc/yum.repos.d to enable.
If you find problems with the packaging, please let me know. If you
find other bugs, please file them in redmine and help make 2.6.0 as
solid as possible for everyone:
http://projects.puppetlabs.com/projects/puppet/issues
Thanks to everyone who contributed code (from Puppet Labs and
elsewhere) for all these cool new features and improvements!
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Politicians are interested in people. Not that this is always a
virtue. Fleas are interested in dogs.
-- P.J. O'Rourke
Dwaalspoor 98
Thanks for your reply! There was not much of interest in the log
files, but the problem I faced is described here:
http://projects.puppetlabs.com/issues/4220
James Turnbull
It's fixed in RC3 if you can test please.
Thanks
Jasper Poppe
>
> Thanks
>
> James Turnbull
>
I've installed RC3 on the master and the client, but I still have
issues if I take for example our Munin (module) class I get the
following error:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find class munin::server in namespaces cs-ops at
/etc/puppet/modules/configs/cs-ops/manifests/init.pp:25 on node
cs-ops001b.intern.marktplaats.nl
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
This is with all the classes in one file (modules/shared/munin/init.pp:
class munin {
package { [ 'munin-node', 'munin-plugins-extra' ]:
ensure => installed;
}
user { 'munin':
require => Package['munin'];
}
group { 'munin':
require => Package['munin'];
}
}
class munin::server inherits munin {
package { 'munin':
ensure => installed;
}
}
If I move the 'class munin::server class' to server.pp I get the
following error:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find parent resource type 'munin' of type hostclass
at /etc/puppet/modules/shared/munin/manifests/server.pp:1 on node
cs-ops001b.intern.marktplaats.nl
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
If you need more info please ping me.
off topic: is it fine if I reply my problems to the release
announcements, or should I file bugs? Since I've quite a few other
problems with 2.6.
Regards,
Jasper Poppe
Peter Meier
Hash: SHA1
> off topic: is it fine if I reply my problems to the release
> announcements, or should I file bugs? Since I've quite a few other
> problems with 2.6.
I think that filing bugs with as much information as you can put into
(client AND server debug/trace logs) is better, as parsing the list for
potential issues is less comfortable than a bug tracker.
But that's my opinion...
cheers pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkw9zh4ACgkQbwltcAfKi39n7ACgp25HqdSi0p8vV0DJWiXxGCMG
N9UAnA2Mr0yAa49XuffQByNl5L8udZmy
=kAbS
-----END PGP SIGNATURE-----
Jasper Poppe
> (client AND server debug/trace logs) is better, as parsing the list for
> potential issues is less comfortable than a bug tracker.
>
> But that's my opinion...
OK, will start filing bugs right now..
Jasper Poppe
> OK, will start filing bugs right now..
>
First bug filed, still 2 more questions before I will file more bugs
since I'm not to sure it's by design or a bug.
1) Do external nodes don't accept parameters anymore? (Not a big deal
for us since we are deprecating those anyway but still different
behavior)
Master error:
err: Failed when searching for node cs-ops001b.intern.marktplaats.nl:
undefined method `parameters=' for #<Puppet::Node:0xb6f2b8ac>
Client error:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed when searching for node
cs-ops001b.intern.marktplaats.nl: undefined method `parameters=' for
#<Puppet::Node:0xb6f2b8ac>
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Stripped YAML Output:
--- %YAML:1.0
"classes": ["cs-ops"]
"parameters":
"cmdb_generated": 1
"company": "CustomerSupport"
"vendor": "Dell"
2) In the output of the client when using puppetd --test I see more
output then previous versions, for example:
cs-ops001b:/home/seedpimp/rc3# puppetd --test
info: Retrieving plugin
info: /File[/var/lib/puppet/lib]: Setting mode to 493
info: /File[/var/lib/puppet/lib]: Storing newly-audited value for content
info: /File[/var/lib/puppet/lib/facter]: Setting mode to 493
info: /File[/var/lib/puppet/lib/facter/conterm.rb]: Setting mode to 420
info: /File[/var/lib/puppet/lib/facter/conterm.rb]: Setting content to
{md5}2d189bceaac522ae1f78d171b8e45531
info: Loading facts in conterm
info: Loading facts in conterm
info: Caching catalog for cs-ops001b.intern.marktplaats.nl
info: Applying configuration version 'ref="refs/heads/master"
commit=212f99a4bce8f2b9edc5254d05d16573a2a84057'
info: /Stage[main]/Nginx/File[/etc/nginx/nginx.conf]: Setting content
to {md5}481ca4ffd65e9c8ae3268b38cfaabfa2
info: /Stage[main]/Nginx/File[/etc/nginx/cert.key]: Setting content to
{md5}9351a9b772c885c8e295541fe11a1c04
info: /Stage[main]/Nginx/File[/etc/nginx/cert.pem]: Setting content to
{md5}48bad668bd52b934aaa7be007be55ead
info: /Stage[main]/Nginx/File[/etc/nginx/sites-available/nginx_status]:
Setting content to {md5}9b3770d588ff756612471634ecf7c1e2
info: /Stage[main]/Cacti/File[/var/cache/debconf/cacti.seed]: Setting
content to {md5}71d829ca1c120c8c98a45299941f6af6
info: /Stage[main]/Nscd/File[/etc/nscd.conf]: Setting content to
{md5}2e06eeb94b8fe8085d8cbd0af118f93e
info: /Stage[main]/Nginx/File[/etc/nginx/sites-available/default]:
Setting content to {md5}e732b889d790c1000c3a1c1c39be000
Those Setting content to lines keep returning every run, and are
exactly the same.
James Turnbull
>
> off topic: is it fine if I reply my problems to the release
> announcements, or should I file bugs? Since I've quite a few other
> problems with 2.6.
>
You should file bugs. We may miss a mailing list post.
Regards