On Tue, May 14, 2013 at 03:34:00PM +0000, Hugo Trippaers wrote: > Hey all, > > We have invested a lot of effort in creating upgrade paths from > older releases to the latest version. As a sysadmin this is one of > the things I value CloudStack for. > > However as a developers there are some drawbacks to this. It means > every time we release a new version we need to QA the entire upgrade > path to check if users can upgrade to this new versions. With the > speed and features we are picking up, I'm expecting this to become a > large burden in the near future. My proposal would be to draw a line > somewhere. Personally I think it would be ok to say to a user that > wants to upgrade from version 2.2.14 to 4.2 to first upgrade to > version 4.0.x en than upgrade to 4.2.x. For our code it does not > really matter that much, but it does matter for QA and packaging. > > For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are > covered by the 4.0 release. If we run into trouble, we release a > maintenance release of that version. QA for new versions should > focus on a stable upgrade path for one or two recent versions and > can "ignore" old versions in the process. With only a few versions > to test against we could also automate parts of this. > > For packaging it is also great. Especially with the current changes > in naming (from cloud to cloudstack) and potential future changes to > integrate better with distributions it becomes handy to be able to > have short upgrade paths. How reasonable is it to have an upgrade > path for 2.2.14 in the RPM when that rpm is built for RedHat 7. > > I would be in favor of supporting upgrades from the first major > release in any series. For example 4.1, 4.2 and 5.0 should have a > tested upgrade path from 4.0. 5.1 would have an upgrade path only > from 5.0. > > What do you guys think? >
This should probably go to user@ as well considering a lot of sysadmins/operators are pained by our upgrades. As you've listed there's two areas where we can improve: QA upgrade testing and the packaging. I'll speak for the former here since it is mostly a manual process now: The major drawback of our upgrade is the need for the server to be running to perform an upgrade making automating it a difficult task. Many of the upgrade issues stem from improper schema scripts. If the database upgrade itself can be separated and performed across versions (any X to any Y) it can easily be scripted and run for every script change in setup/db. There's proven methods of doing database change managment [1] and we've taken a good first step in establishing a base schema [2] at 4.0. It's probably the right time to think about these things now that 4.1 has been stalling for a while with upgrade issues. [1] http://blog.42.nl/articles/automate-liquibase-migrations/ [2] http://odetocode.com/blogs/scott/archive/2008/01/31/versioning-databases-the-baseline.aspx -- Prasanna., ------------------------ Powered by BigRock.com
