Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-users@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of rohityadav89@gmail.com
 designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
Sender: rohityadav89@gmail.com
From: Rohit Yadav <bhaisaab@apache.org>
Date: Thu, 14 Feb 2013 14:58:38 +0530
Message-ID: 
 <CANLSSBU+BuxALp=W9SFn=pcAwLCH70j5+Hsvk+t-WEYOFc2gEw@mail.gmail.com>
Subject: [PROPOSAL] DatabaseCreator: the db deployer,
 dbv upgrader and db cleaner
To: cloudstack-dev@incubator.apache.org, cloudstack-users@incubator.apache.org
Cc: alex.huang@apache.org, Abhinandan Prateek <Abhinandan.Prateek@citrix.com>
Content-Type: text/plain; charset=ISO-8859-1

Had discussions with Alex and Abhi on DatabaseCreator. I was earlier
not sure why we need it or how sysadmins would use it.
We had a hangout on G+: https://www.youtube.com/watch?v=Xp2AGii1szQ

Let's talk about the present database deployment and the issues:
- We've two different routes to deploydb, for developers it's
DatabaseCreator now (used to be a maven plugin), for sysadmins it's
cloudstack-setup-database
- Upgrades are done by mgmt server, this has issues when there is a
clustered mgmt server, i.e. multiple mgmt servers sharing the same
database, we do upgrade by:
     a. Turn down one mgmt server, upgrade it, start it. This mgmt
server checks in db the cloudstack version, upgrades the db
     b. Sysadmins meanwhile upgrades all the other mgmt server
     c. When all mgmt servers are upgraded, they ask the cluster
manager to run the cleanup. The whole process is automated, an error
can introduce whole sets of issues.

How will DatabaseCreator help:
- Would give a single tool used by both developer and sysadmins. Agony
of the sysadmins would be much better understood by developers.
Sysadmins would still use cloudstack-setup-database which would be
wrapper around DatabaseCreator
- Upgrade would be driven by sysadmin, giving them explicit power to
backup database, deploy etc. For example in case of multiple
(clustered) mgmt server, the upgrade would be like:
   a. Upgrade database using DatabaseCreator, this step do a backup
and would just upgrade the db such that it's backward compatible to
the old database and old mgmt servers can still run on it. When this
succeeds, system can proceed. Transaction update would provide a way
to rollback.
   b. Sysadmins would stop, upgrade and start mgmt server one by one.
   c. Sysadmins would run the final cleanup operation, this would do a
final round of cleaning up. If everything goes well, they just did a
rolling CloudStack upgrade with little to no downtime (no downtime as
at least one mgmt server was running :)

TODOs for 4.1:
- We stick to major db version as 4.0, create-schema is not touched
unless it's a major version. So, next change is to be done only for
5.0.
- We move out any 4.1 changes to 4041 upgrade sql file and have a
upgrade path (a upgrading logic/class).
- Fix cloudstack-setup-databases, fix packaging.

For 4.2/future:
- Refactor out code that does upgrading in mgmt server to a separate
artifact which would also have DatabaseCreator.
- Implement tool so it supports the operations as discussed above
- Replace the current pythonic implementation with DatabaseCreator,
have same routes for both developers and sysadmins

NOTE TO DEVELOPERS:
- WE NEVER CHANGE create-schema.sql
- WE TEST AND IMPLEMENT UPGRADE PATHS from version a to version b
- WE CLEANUP PROPERLY via our upgrade sql files and upgrade classes

Comments, suggestions, flames?

Regards.