cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <min.c...@citrix.com>
Subject Re: database creator
Date Wed, 17 Apr 2013 16:49:53 GMT
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" <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
View raw message