# How to handle upgrades - Looking for good practices

**URL:** <https://discourse.chef.io/t/how-to-handle-upgrades-looking-for-good-practices/1533>\
**Category:** Chef Infra (archive)\
**Created:** [August 13, 2010, 6:11pm UTC](https://discourse.chef.io/t/how-to-handle-upgrades-looking-for-good-practices/1533 "2010-08-13T18:11:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Patrick\_Debois](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/patrick_debois/32/440_2.png) [@Patrick\_Debois](https://discourse.chef.io/u/Patrick_Debois)\
**Post date:** [August 13, 2010, 6:11pm UTC](https://discourse.chef.io/t/how-to-handle-upgrades-looking-for-good-practices/1533/1 "2010-08-13T18:11:19Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Jesse\_Nelson](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_nelson/32/262_2.png) [@Jesse\_Nelson](https://discourse.chef.io/u/Jesse_Nelson)\
**Post date:** [August 13, 2010, 10:10pm UTC](https://discourse.chef.io/t/how-to-handle-upgrades-looking-for-good-practices/1533/2 "2010-08-13T22:10:09Z")

</div>

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