Hi chefs,
I’m wondering how you guys would handle the following scenario:
Let’s say I want to upgrade the version of Tomcat 5.x to a new version 5.x+1
- Tomcat isn’t installed by an RPM so I can’t use the upgrade of a package
- The Tomcat 5.x has been installed through a recipe
- The installation of the 5.x is similar to the 5.x+1 one
_
Question1:_
On a server that has no tomcat installed yet, I could use the version as
a attribute and use the same recipe.
In the cloud I can get a new machine and disable and enable it in the
loadbalancer pool.
Still in some enterprise they don’t use the cloud and don’t have
machines/power lying around.
So what should I do:
- write a new upgrade recipe for 5.x -> 5.x+1?
- integrate it into the existing tomcat recipe?
- create a package out of it and use the upgrade
- other
_
Question2:_
In some organizations they have several versions of tomcat running and
they can’t be upgraded at the same time (might be because of downtime
depending on the SLA of the customer, application compabitility, …) In
these environments you may end up with versions ranging from 5.x -> 6.x+N
It reminds me of ‘rails database migrations’ , where your schema.rb is
the result of several migrations and you have to sequence the recipes played
In the dev and test environment I want to do the same sequence of
recipes as the production one did. And if production has undergone a
sequence I want dev and test to do the same sequence.
_Question 3:
_This kind of upgrades can fail , it would be nice to have a way to make
them transactional. Apart from snapshotting the machine+data, any
examples on how to handle this in ‘upgrade’ recipes?
I would really be grateful for blogposts or any info on this. I’ve
searched a bit but only found the ‘first installation’ scenario’s, not
this kind of upgrade scenario. Or it might be me not fully understanding
the way to handle this.
Patrick