Puppet users - Jul 2010 - ANNOUNCE: Puppet 2.6.0 - Final release!

The journey was long and arduous and many fell along the way but Puppet
Labs is proud to announce the 2.6.0 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.

We''ve included release notes below that you can also see at:

http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

The release is available for download at:

http://puppetlabs.com/downloads/puppet/puppet-2.6.0.tar.gz

Please note that the release is signed with the new Puppet Labs key and
the signature is available at:

http://puppetlabs.com/downloads/puppet/puppet-2.6.0.tar.gz.sign

See the Verifying Puppet Downloads section at
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report any feedback via the Puppet Labs Redmine site:

http://projects.puppetlabs.com

Please select an affected version of 2.6.0.

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

See the full list of tickets closed at:

http://projects.puppetlabs.com/projects/puppet/issues?fixed_version_id=23&set_filter=1&status_id=c

Regards

James Turnbull

-- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

James Turnbull said:
> The journey was long and arduous and many fell along the way but Puppet
> Labs is proud to announce the 2.6.0 release!
> 
Is anyone aware of an attempt to package up a complete (puppet + all
prereqs) installer for Windows?  Either official, or by someone in the
community?

And, asking from the other direction: would anyone else be interested in
such a thing?

I would be, because setting up puppet on Windows seems pretty tough
right now.  I also have no need for Ruby on my Windows boxes except
for the usage of puppet.
-- 
Rohan McGovern
QA Engineer
Qt Development Frameworks, Nokia

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 2010-07-20 01:40, Rohan McGovern wrote:
> And, asking from the other direction: would anyone else be interested in
> such a thing?
> 
I know the company I work for would be very interested in having it
packaged for Windows.

The last time I asked on IRC, the Windows support was coming along but
was not quite there yet.
What features are currently working properly and what are the ones that
are lacking?

-- 
Gabriel Filion

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jul 19, 10:23 pm, James Turnbull <ja...@puppetlabs.com>
wrote:
> The journey was long and arduous and many fell along the way but Puppet
> Labs is proud to announce the2.6.0release!
>
> The2.6.0release 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.
>
> We''ve included release notes below that you can also see at:
>
> http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
>
> The release is available for download at:
>
> http://puppetlabs.com/downloads/puppet/puppet-2.6.0.tar.gz
>
> Please note that the release is signed with the new Puppet Labs key and
> the signature is available at:
>
> http://puppetlabs.com/downloads/puppet/puppet-2.6.0.tar.gz.sign
>
> See the Verifying Puppet Downloads section
athttp://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
>
> Please report any feedback via the Puppet Labs Redmine site:
>
> http://projects.puppetlabs.com
>
> Please select an affected version of2.6.0.
>
> RELEASE NOTES
>
> Language
>
> Support for parameterised classes
>
> The2.6.0release 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 (seehttp://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
>
> See the full list of tickets closed at:
>
> http://projects.puppetlabs.com/projects/puppet/issues?fixed_version_i...
>
> Regards
>
> James Turnbull
>
> -- Puppet Labs -http://www.puppetlabs.comC: 503-734-8571
With this release, are all of the training courses you do now based on
2.6.0 and higher, or is that migration still in progress? What does
the roadmap look like for making the documentation 2.6.x centric?

Congrats on this release, looks like a big one, and I''m looking
forward to diving in.

Pete

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Aug 5, 2010, at 12:18 PM, Pete Emerson <pemerson@gmail.com>
wrote:
> With this release, are all of the training courses you do now based on
> 2.6.0 and higher, or is that migration still in progress? What does
> the roadmap look like for making the documentation 2.6.x centric?
Our training courses have not been updated to 2.6 materials yet, but
will be very soon.  There''s quite a bit of material to update with
this release.

--
Jeff McCune

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Jul 19, 2010 at 10:23 PM, James Turnbull <james@puppetlabs.com>
wrote:
> The journey was long and arduous and many fell along the way but Puppet
> Labs is proud to announce the 2.6.0 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.
>
> We''ve included release notes below that you can also see at:
>
> http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
Cool. Did autoloaded module names in parameterized classes get fixed?
Ie, in the 2.6 rc I tried using, you couldn''t go:

class { syslog::server: version => "1.3.13" }

Also, seems like a lot of people where having trouble getting
parameterized classes to work at all. Curious to see if that works
now.

Doug.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/07/2010 12:29 AM, Douglas Garstang wrote:
> On Mon, Jul 19, 2010 at 10:23 PM, James Turnbull
<james@puppetlabs.com> wrote:
>> The journey was long and arduous and many fell along the way but Puppet
>> Labs is proud to announce the 2.6.0 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.
>>
>> We''ve included release notes below that you can also see at:
>>
>> http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
> 
> Cool. Did autoloaded module names in parameterized classes get fixed?
> Ie, in the 2.6 rc I tried using, you couldn''t go:
> 
> class { syslog::server: version => "1.3.13" }
> 
> Also, seems like a lot of people where having trouble getting
> parameterized classes to work at all. Curious to see if that works
> now.
have a look at the bugreport to track that issue.

cheers pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxfJ1gACgkQbwltcAfKi38EPACffQ3dpZGWg187UlLP+jPqByfU
hqkAnR8aiytcejnPoD5RdE2+fwEuWlLl
=5gST
-----END PGP SIGNATURE-----

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sun, Aug 8, 2010 at 2:54 PM, Peter Meier <peter.meier@immerda.ch>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/07/2010 12:29 AM, Douglas Garstang wrote:
>> On Mon, Jul 19, 2010 at 10:23 PM, James Turnbull
<james@puppetlabs.com> wrote:
>>> The journey was long and arduous and many fell along the way but
Puppet
>>> Labs is proud to announce the 2.6.0 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.
>>>
>>> We''ve included release notes below that you can also see
at:
>>>
>>> http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
>>
>> Cool. Did autoloaded module names in parameterized classes get fixed?
>> Ie, in the 2.6 rc I tried using, you couldn''t go:
>>
>> class { syslog::server: version => "1.3.13" }
>>
>> Also, seems like a lot of people where having trouble getting
>> parameterized classes to work at all. Curious to see if that works
>> now.
>
> have a look at the bugreport to track that issue.
Seems a bit weird to me that one of the new features would not working
in the final release...

Doug.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Aug 9, 2010 at 8:27 AM, Douglas Garstang
<doug.garstang@gmail.com> wrote:
> On Sun, Aug 8, 2010 at 2:54 PM, Peter Meier <peter.meier@immerda.ch>
wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 08/07/2010 12:29 AM, Douglas Garstang wrote:
>>> On Mon, Jul 19, 2010 at 10:23 PM, James Turnbull
<james@puppetlabs.com> wrote:
>>>> The journey was long and arduous and many fell along the way
but Puppet
>>>> Labs is proud to announce the 2.6.0 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.
>>>>
>>>> We''ve included release notes below that you can also
see at:
>>>>
>>>>
http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
>>>
>>> Cool. Did autoloaded module names in parameterized classes get
fixed?
>>> Ie, in the 2.6 rc I tried using, you couldn''t go:
>>>
>>> class { syslog::server: version => "1.3.13" }
>>>
>>> Also, seems like a lot of people where having trouble getting
>>> parameterized classes to work at all. Curious to see if that works
>>> now.
>>
>> have a look at the bugreport to track that issue.
>
> Seems a bit weird to me that one of the new features would not working
> in the final release...
New features seem like a perfectly reasonable place for new bugs to
appear to me actually :)

After poking around looking at the bugs people filed, it just seems
like it wasn''t tested fully enough. It passes simple test cases.

>
> Doug.
>
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
nigel

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Aug 9, 2010 at 9:30 AM, Nigel Kersten <nigelk@google.com>
wrote:
> On Mon, Aug 9, 2010 at 8:27 AM, Douglas Garstang
> <doug.garstang@gmail.com> wrote:
>> On Sun, Aug 8, 2010 at 2:54 PM, Peter Meier
<peter.meier@immerda.ch> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 08/07/2010 12:29 AM, Douglas Garstang wrote:
>>>> On Mon, Jul 19, 2010 at 10:23 PM, James Turnbull
<james@puppetlabs.com> wrote:
>>>>> The journey was long and arduous and many fell along the
way but Puppet
>>>>> Labs is proud to announce the 2.6.0 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.
>>>>>
>>>>> We''ve included release notes below that you can
also see at:
>>>>>
>>>>>
http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
>>>>
>>>> Cool. Did autoloaded module names in parameterized classes get
fixed?
>>>> Ie, in the 2.6 rc I tried using, you couldn''t go:
>>>>
>>>> class { syslog::server: version => "1.3.13" }
>>>>
>>>> Also, seems like a lot of people where having trouble getting
>>>> parameterized classes to work at all. Curious to see if that
works
>>>> now.
>>>
>>> have a look at the bugreport to track that issue.
>>
>> Seems a bit weird to me that one of the new features would not working
>> in the final release...
>
> New features seem like a perfectly reasonable place for new bugs to
> appear to me actually :)
>
> After poking around looking at the bugs people filed, it just seems
> like it wasn''t tested fully enough. It passes simple test cases.
For release candidates though, not the final release. If it doesn''t
work with the final release, it should be noted in the documentation
that it doesn''t work. It doesn''t seem to work for autoloaded
classes,
which, at least in my world, makes it useless.

Doug.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Douglas Garstang wrote:
>>
>> After poking around looking at the bugs people filed, it just seems
>> like it wasn''t tested fully enough. It passes simple test
cases.
> 
> For release candidates though, not the final release. If it
doesn''t
> work with the final release, it should be noted in the documentation
> that it doesn''t work. It doesn''t seem to work for
autoloaded classes,
> which, at least in my world, makes it useless.
So we had an extensive release candidate process - during which a fairly
small number of people tested a number of features including PL people
internally.  The examples of parametrized classes we tested were not
sufficiently extensive to identify the problem.

Interestingly tracking the history of this - you did call out a problem
with 2.6.0rc1 on the mailing list but didn''t log a ticket until well
after the release was marked final 7/19 versus 7/30.  That ticket
(http://projects.puppetlabs.com/issues/4405) appears to be have been a
moot issue - it''s not clear to me that there was a problem in the first
place.  Later, a ticket was logged
(http://projects.puppetlabs.com/issues/4423) again after 2.6.0 was
released by Jeff McCune based on his further testing and exposition of
your emails.

Overall, from this I''d mention that it is critical to us that people
log
tickets - we can''t always follow every thread on the mailing list.  If
you find a bug then log a ticket as quickly as possible - include the
version, your platform, an accurate and simple as possible manifest
example of your issue, etc, etc.  If we don''t act on your ticket then
bug us until we do.  Best of all - submit bug fixes or patches.

Regards

James Turnbull

-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.