On Wed, Apr 17, 2013 at 10:19 PM, Min Chen <min.c...@citrix.com> wrote:
> 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. > +1 it's just some upgrade done not by mgmt server but the tool explicitly. Cheers. > > 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. > >
