[chef] Re: How to handle upgrades - Looking for good practices

[Jesse Nelson < >]

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
>