cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: database creator
Date Wed, 17 Apr 2013 17:43:57 GMT
On Wed, Apr 17, 2013 at 10:19 PM, Min Chen <min.chen@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" <bhaisaab@apache.org> wrote:
>
> >On Tue, Apr 16, 2013 at 7:33 PM, Abhinandan Prateek
> ><cloudstack@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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message