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 |
Archive powered by MHonArc 2.6.16.