Announce: Ruby 2.3 update planned for puppet-agent 1.6.0

[Geoff Nichols]

Because Ruby 2.1 is approaching end-of-life (upstream bugfix support ended March 2016), we need to move puppet-agent to a more modern Ruby version.

If all goes well with testing, the upcoming puppet-agent 1.6.0 release will include Ruby 2.3.1.

Since the update to Ruby 2.3 is a minor release for Ruby, we're including it in a minor release of puppet-agent.

However, user-installed gems in puppet-agent's gem path will require re-installation following the upgrade to puppet-agent 1.6.0. (If you think this will affect you, please let us know how, and we’ll look into it.)

If you have any questions about this, please don’t hesitate to ask.

--

Geoff Nichols

Puppet Release Engineering

PuppetConf 2016, 19 - 21 October, San Diego, California

Summer Savings - Register by 15 September and save $240

[Francois Lafont]

Hi,

On 30/07/2016 02:00, Geoff Nichols wrote:

> Because Ruby 2.1 is approaching end-of-life (upstream bugfix support ended
> March 2016), we need to move puppet-agent to a more modern Ruby version.
>
> If all goes well with testing, the upcoming puppet-agent 1.6.0 release will
> include Ruby 2.3.1.
>
> Since the update to Ruby 2.3 is a minor release for Ruby, we're including
> it in a minor release of puppet-agent.
>
> However, user-installed gems in puppet-agent's gem path will require
> re-installation following the upgrade to puppet-agent 1.6.0. (If you think
> this will affect you, please let us know how, and we’ll look into it.)
>
> If you have any questions about this, please don’t hesitate to ask.

1. So it concerns gems installed via this command:

/opt/puppetlabs/puppet/bin/gem install $gem_foo

Is it correct?


2. And what about gems installed via this command?

/opt/puppetlabs/bin/puppetserver gem install $gem_foo

Is a re-installation after the upgrade needed too?


Thanks in advance for your help.
François Lafont

[Martin Jackson]

We depend on hiera-eyaml, which is going to make the upgrade kind of tricky for us. 

Has there been any thought to including hiera-eyaml in puppet enterprise proper?

Thanks,

Marty 

[Geoff Nichols]

On Friday, July 29, 2016 at 7:48:26 PM UTC-7, François Lafont wrote:

Hi,

On 30/07/2016 02:00, Geoff Nichols wrote:

> Because Ruby 2.1 is approaching end-of-life (upstream bugfix support ended
> March 2016), we need to move puppet-agent to a more modern Ruby version.
>
> If all goes well with testing, the upcoming puppet-agent 1.6.0 release will
> include Ruby 2.3.1.
>
> Since the update to Ruby 2.3 is a minor release for Ruby, we're including
> it in a minor release of puppet-agent.
>
> However, user-installed gems in puppet-agent's gem path will require
> re-installation following the upgrade to puppet-agent 1.6.0. (If you think
> this will affect you, please let us know how, and we’ll look into it.)
>
> If you have any questions about this, please don’t hesitate to ask.

1. So it concerns gems installed via this command:

    /opt/puppetlabs/puppet/bin/gem install $gem_foo

Is it correct?

Yes, that's correct.

2. And what about gems installed via this command?

    /opt/puppetlabs/bin/puppetserver gem install $gem_foo

Is a re-installation after the upgrade needed too?

No, gems installed using Puppet Server's `puppetserver gem install` subcommand use a separate (JRuby) interpreter. Those gems should not be affected and should not require re-installation after the upgrade.

[Francois Lafont]

Hi,

On 02/08/2016 06:28, Geoff Nichols wrote:

>> 1. So it concerns gems installed via this command:
>>
>> /opt/puppetlabs/puppet/bin/gem install $gem_foo
>>
>> Is it correct?
>>
>
> Yes, that's correct.

Ok.

>> 2. And what about gems installed via this command?
>>
>> /opt/puppetlabs/bin/puppetserver gem install $gem_foo
>>
>> Is a re-installation after the upgrade needed too?
>>
>
> No, gems installed using Puppet Server's `puppetserver gem install`
> subcommand use a separate (JRuby) interpreter. Those gems should not be
> affected and should not require re-installation after the upgrade.

Ok.

Thanks for your answer Geoff. But, in this case, I don't really see the
impact of this migration Ruby 2.1 => 2.3 in a classical "clients/server"
architecture (I mean the impact for the _user_ because I imagine there are
eventually impacts for the puppet-agent developer ;)).

For instance, I have installed hiera-eyaml but it's for the server
(so I have made "/opt/puppetlabs/bin/puppetserver gem install hiera-eyaml").
I have installed hiera-eyaml with the "puppet" command too, to just
have the "eyaml" command in my PATH too (ie in /opt/puppetlabs/puppet/bin/)
but it's just for convenience.

Another example: if I have ruby functions in my puppet modules, these
functions are executed in the server side, so no impact too in this case,
correct ?

In fact, where could be the "user" impacts of this change? The only thing
I see is "custom facts" in modules which are Ruby code executed in clients
side. Are there another things which I need to check carefully in the
clients/server architecture?

Regards.


François Lafont

[R.I.Pienaar]

There are still people who do not use puppetserver but passenger. And many
who use apply only.

[Francois Lafont]

Hi,

On 02/08/2016 14:44, R.I.Pienaar wrote:

> There are still people who do not use puppetserver but passenger.

Ok, indeed, in this case the migration can have bigger impact.
But with puppetserver , am I wrong if I say that the only thing
which can be impacted by this migration is the custom facts?

> And many who use apply only.

Yes indeed.

François Lafont

[Geoff Nichols]

On Friday, July 29, 2016 at 5:00:26 PM UTC-7, Geoff Nichols wrote:

Because Ruby 2.1 is approaching end-of-life (upstream bugfix support ended March 2016), we need to move puppet-agent to a more modern Ruby version.

If all goes well with testing, the upcoming puppet-agent 1.6.0 release will include Ruby 2.3.1.

As an update, we found some issues during testing, so puppet-agent 1.6.0 will NOT include Ruby 2.3.1. 

We're now targeting the Ruby 2.3 update for a later puppet-agent release. (We'll share more information about that timeframe as the plan firms up.)   

Thanks,

Geoff

[Garrett Honeycutt]

Hi Geoff,

It seems that the testing is leaving out the huge dataset of modules
from the Forge. Checked out the TravisCI configs for a couple of the top
supported modules including stdlib, apache, ntp, apt and vcsrepo and
none of them are testing with ruby 2.3. Suggest that before moving to a
new version of ruby, the TravisCI configs for all supported modules
should be explicitly testing against the new ruby version to ensure it
works.

For those curious about adding support for ruby 2.3.1, here's an example
TravisCI config.

https://github.com/ghoneycutt/puppet-module-ssh/blob/master/.travis.yml

Best regards,
-g


--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[Ethan Brown]

On Monday, August 8, 2016 at 8:30:27 PM UTC-7, Garrett Honeycutt wrote:

On 8/5/16 9:12 PM, Geoff Nichols wrote:
>
>
> On Friday, July 29, 2016 at 5:00:26 PM UTC-7, Geoff Nichols wrote:
>
>     Because Ruby 2.1 is approaching end-of-life (upstream bugfix support
>     ended March 2016), we need to move puppet-agent to a more modern
>     Ruby version.
>
>
>     If all goes well with testing, the upcoming puppet-agent 1.6.0
>     release will include Ruby 2.3.1.
>
>
> As an update, we found some issues during testing, so puppet-agent 1.6.0
> will NOT include Ruby 2.3.1.
>
> We're now targeting the Ruby 2.3 update for a later puppet-agent
> release. (We'll share more information about that timeframe as the plan
> firms up.)  
>
> Thanks,
> Geoff
>

Hi Geoff,

It seems that the testing is leaving out the huge dataset of modules
from the Forge. Checked out the TravisCI configs for a couple of the top
supported modules including stdlib, apache, ntp, apt and vcsrepo and
none of them are testing with ruby 2.3. Suggest that before moving to a
new version of ruby, the TravisCI configs for all supported modules
should be explicitly testing against the new ruby version to ensure it
works.

We have tested on some Windows modules with success.  Generally speaking, I believe we're more likely to see issues in modules that have Ruby type and provider code than we are in modules that are primarily manifest driven.

That said, I totally agree we should get module testing changes rolled out officially ASAP.  For the Windows modules, we'll plan on getting all the Travis / AppVeyor updates in place over the next few days.  Contact has been made with the owners of the other modules to do the same.

I did identify some issues in core Puppet around module loading on Windows, thanks to Ruby changing the behavior of Dir.glob when given 8.3 style paths - that ticket is at https://tickets.puppetlabs.com/browse/PUP-6557 / PR is at https://github.com/puppetlabs/puppet/pull/5156 and should be merged shortly.

Thanks!

Ethan J. Brown

Tech Lead, Windows Engineering