In my opinion, rolling upgrade may not be an accurate term here for this task. In my previous experience, rolling upgrade is defined as a upgrade process that allows users to keep their existing distributed system running while they upgrade each system gradually. I don't think that this is the case we are trying to achieve here, and I would suggest stopping using that term to avoid confusion.
Thanks -min On 4/17/13 6:25 AM, "Rohit Yadav" <bhais...@apache.org> wrote: >On Tue, Apr 16, 2013 at 7:33 PM, Abhinandan Prateek ><cloudst...@aprateek.com >> wrote: > >> >> I have some queries regarding Database Creator: >> >> Can this feature be tested on 4.1 ? >> > >No, it's only in master. But starting 4.2, all ACS versions will have that >until they will have dbcreator. > >For 4.1, we don't have rolling upgrade during fresh db setup using >cloudstack-database-setup. In 4.1, when mgmt server would start, it would >do the upgrade (or one of the clustered mgmt servers) like before. For >4.2, >it would upgrade at the time of fresh deployment. > > >> >> Could someone also provide more details on the following:**** >> >> **** >> >> 1. Outline the exact steps that are involved in rolling upgrade >>procedure? >> > >Wiki! Get the src and try it yourself. > > **** >> >> 2. Can you confirm if rolling upgrades are specific to only upgrade >> procedure involving multiple management servers in a cluster? >> > >No, as mentioned. For 4.1, like before. Starting 4.2/master, the tools >should be called explicitly to upgrade db or deploy a fresh db. More on >3.; > > > >> **** >> >> 3. Would rolling upgrades mean that there will be zero downtime for >> customers when upgrading? Are we also dealing with NOT having to restart >> all system Vms ? Currently restarting system Vms is part of our upgrade >> procedure. >> > > >So not really, while on paper and on wiki would give you zero downtime. >The idea is: > >For fresh installation, it's a no brainer. I will refer to "tool" as the >utility (cloudstack-database-setup or databasecreator). For existing >deployments in case of a mgmt server cluster: > >- Admin shuts down one server, upgrades cloudstack and gets >cloudstack-setup-database or databasecreator. >- Admin uses the tool to upgrade CloudStack db to a state that is backward >compatible to the old db version. >- Next Admin starts CS on that server and stop-upgrade-starts CS on each >servers. >- When all are up, admin calls the cleanup logic to cleanup. > >Note: We got the databasecreator, but its not smooth. > >I'm not in a state to work on CloudStack fulltime now, someone pl. help us >to: >- fix packaging and java classpath in cloudstack-setup-database and also >fix args processing and pass them to dbcreator via the python script >- test the whole thing, the explicit calling of cleanup and upgrade are >not >different now. Right now with dbcreator you can either do fresh >deployments >or upgrades only. Clean+Upgrade is united. >- test and fix any bugs, imo for a really large deployment using older >versions of CS, the transition won't be smooth. But for ACS 4.0+ >deployments, we can theoretically expect zero downtime. > >Cheers.
