Gotchas around upgrading from an old version (0.25.4) to a newer version.

[brokenpipe]

I've been tasked at my workplace to upgrade our puppet installation to
a more modern version. Currently all the environments run a RubyGem
version of puppet 0.25.4 on mostly RHEL/Centos 5.3 - 5.5 (there are,
like most environments, a few laggards running RHEL4 or new machines
running CentOS 6).

The plan is to upgrade these to the most stable version of Puppet,
which at the time of writing is 2.7.3.

I plan on building RPMs on RHEL5.3 for Puppet 2.7.3 against the Ruby
version that RHEL5 shipped with which is 1.8.5 I believe.

Are there are any significant gotaches. My plan was to upgrade the
server first and then do a few roll outs to some QA machines and see
how it goes. However there is some concern in the group that 0.25.4
agents are unable to talk to a 2.7.3 server. Are these unfounded or
true?

[Brian Gupta]

If you follow the mailing list it seems that there were a larger number of deliberate syntax changes from the move from 2.6 to 2.7 than there were from 0.25 to 2.6. IE: Syntax that changes behavior, not just breaks.

The rule of thumb has always been to support one major version backwards, so a 2.7 server should in theory support 2.6 clients, and 0.25 clients less so. YMMV, as there really isn't a strict guarantee of backwards compatibility in any case.

Check out: http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes and you'll see the 2.7 release had a lot more changes than the 2.6 branch.

You are likely to have fewer issues migrating from 0.25 to 2.6 vs 2.7. 

Two things to consider when you are making this migration.
1) 2.6.9 is a more "stable" code base. (Stable meaning mature and vetted).
1) 2.7.4 is a more featureful, faster-moving code base. (Faster moving because it's the active branch and is newer). We are just now feeling that it is ready for new deployments, so if the features are compelling, maybe the risk and pain of a two major version upgrade might be worth it.

I still think skipping major puppet versions when upgrading is somewhat risky, and I would probably move my environment to 2.6.9 and then plan on a later move to 2.7. I guess for me the deciding factors would be, a) how large is my code base (the smaller it is, the easier it will be to debug any issues that come up), and b) what is my pain tolerance if there are incompatibilities that come up.

-Brian

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

--

[jcbollinger]

On Sep 25, 7:22 pm, Brian Gupta <brian.gu...@brandorr.com> wrote:
> If you follow the mailing list it seems that there were a larger number of
> deliberate syntax changes from the move from 2.6 to 2.7 than there were from
> 0.25 to 2.6. IE: Syntax that changes behavior, not just breaks.

And that affects the server, but not (directly) clients.

> The rule of thumb has always been to support one major version backwards, so
> a 2.7 server should in theory support 2.6 clients, and 0.25 clients less so.
> YMMV, as there really isn't a strict guarantee of backwards compatibility in
> any case.

I was certain that PuppetLabs's commitment was that clients should
continue to work with servers up to *two* major versions newer, thus
0.25 clients should still work with 2.7, but probably not with 2.8.
Am I mistaken?


[...]

> I still think skipping major puppet versions when upgrading is somewhat
> risky, and I would probably move my environment to 2.6.9 and then plan on a
> later move to 2.7. I guess for me the deciding factors would be, a) how
> large is my code base (the smaller it is, the easier it will be to debug any
> issues that come up), and b) what is my pain tolerance if there are
> incompatibilities that come up.

On the other hand, if the ultimate target is 2.7 (and later), then it
may be worthwhile to bite the bullet and do it all at once, instead of
going through the whole process twice. I am confident that the larger
jump would be more work than the smaller, but doing it in two separate
jumps would surely be the most work of all. As for risk, I think
that's much more tightly coupled to the distance you move in version-
number space than to the path you take to get from here to there.

Personally, I would be inclined to jump straight to 2.7, but Brian is
exactly right that you should evaluate your options in light of your
own environment and requirements.


John

[Yvo van Doorn]

Thanks Brian and John for your thorough responses. I'm inclined to
make the jump straight to 2.7.x as well. My plan of attack is to bring
up a clone of the current puppet master VM and upgrade that to 2.7 and
connect a few stage/test servers against it.

I can then work out the kinks of the server and work on clients.

Hopefully this will identify issues, if any (I'm still hopeful), that
need to be remediated.

Yvo

[Paul Morgan]

On Sep 26, 2011 12:08 PM, "Yvo van Doorn" <yvo.va...@gmail.com> wrote:
Snip

>
>
> Thanks Brian and John for your thorough responses. I'm inclined to
> make the jump straight to 2.7.x as well. My plan of attack is to bring
> up a clone of the current puppet master VM and upgrade that to 2.7 and
> connect a few stage/test servers against it.
>
> I can then work out the kinks of the server and work on clients.
>
> Hopefully this will identify issues, if any (I'm still hopeful), that
> need to be remediated.
>

Fwiw I upgrade to 2.6.6, resolved deprecation warnings from the server log, then upgraded to 2.7.3 with no issues.  It was painless.

Hth,
-paul