How to handle upgrades - Looking for good practices

Chef Infra (archive)
1

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

2

we use packages to manage this sort of infrastructure issue, and underlying package pinning to freeze packages at a specific version. This is one reason why we require applications(system level not code in a framework). To be exclusively packaged and shipped to our local repos for dissemination into the infrastructure.

This allows us to easily upgrade a node or role and to keep version tied to metadata (roles/attribs/data bags).

As far as the "upgrade" scenario goes. We tend to just rebuild since building vms is cheap and the application tool-stack is modeled in chef. I prefer to do the build up and flip the switch migrations on infrastructure. This way you can flip that switch back if things go awry. Usually that switch is a balance group on a proxy or a ipvs load balancer that is also managed by chef.

timtowtdi

On Aug 13, 2010, at 11:11 AM, Patrick Debois wrote:

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