On May 14, 2013, at 1:57 PM, David Nalley <da...@gnsa.us> wrote: > On Tue, May 14, 2013 at 1:46 PM, Hugo Trippaers > <htrippa...@schubergphilis.com> wrote: >> >> >> Sent from my iPhone >> >> On 14 mei 2013, at 18:28, "David Nalley" <da...@gnsa.us> wrote: >> >>> On Tue, May 14, 2013 at 11:34 AM, Hugo Trippaers >>> <htrippa...@schubergphilis.com> 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? >>>> >>>> Cheers, >>>> >>>> Hugo >>>> >>>> P.S. ignore the version numbers, just used some random version numbers to >>>> illustrate my ideas. >>> >>> >>> While I generally like this idea - orphaned features have essentially >>> long-stranded folks on old version with no way of upgrade. Think of >>> things like Bare metal, Oracle VM, SG in Advanced Zones, etc. For some >>> of those, I don't see how we'll not have them upgrade from 2.2.x to >>> 4.2. The sysadmin in me thinks we've done a moderate job of supporting >>> upgrades in the past - for some core set of services we've done well, >>> but used anything not 'mainstream' and we have left many folks behind. >>> A lot of that is pre-ASF legacy that for better or worse we still need >>> to deal with. >>> For folks that have used such things, we have essentially abandoned >>> them on whatever version they used them. I think that this should mean >>> that we are much more sober in adding features, to gauge how well we >>> as a community can support those features over the long haul. It also >>> means that deprecations need to be planned. The way we deprecated >>> Oracle VM was horrendous IMO. >> >> You are actually introducing a second point here. > > Yes, I did - sorry about that, but I think it is part of the > conversation, because in many cases they created the problem. See > below as to why. > >> My point was that if we have a stable upgrade path from say version 2.2.14 >> to 4.0 then 4.1 would only need to have an upgrade from 4.0 to 4.1. So >> admins would have to do two different upgrades (talking about packages >> installed on systems) in instead of one as is the case now. >> > > The problem is that we have many that can't upgrade from 2.2.14 to 4.0 > right now. I think 2.2.14 to 4.1 is the closest we'll get, but > wouldn't rool out 2.2.14> 4.2 in some cases. (I know, we are ignoring > version numbers. I think this is fine if we put a stake in the ground > and say we'll get you from 2.2.14 to the jumping off release, but > won't test past that)
I agree with Hugo for the future. But for the present, we still have folks on pre-Apache releases and some have trouble to upgrade. It's a separate thread I suppose, but we need to make sure we on-board everyone that is still on pre 4.0 releases. -Sebastien > >> Your point, if I'm getting it right is about abandoning features and thereby >> users. That's something we agree on, we shouldn't so easily deprecate >> features as we go along. Or at least be very clear about this and explain >> why. I think this warrants a separate thread to discuss this in more detail. >> > > > Agreed - maybe I'll start that one soon. > > --David
