cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Mehta <>
Subject Re: [PROPOSAL] DatabaseCreator: the db deployer, dbv upgrader and db cleaner
Date Thu, 14 Feb 2013 10:06:13 GMT
Thanks Rohit. Had few questions for you. Please find them inline.

On 14/02/13 2:58 PM, "Rohit Yadav" <> wrote:

>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+:
>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
>- 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 :)

Can you please elaborate on the steps you performing here. When will the
transaction be committed here ?
So major advantage of this tool is for rolling upgrade is it ?

>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
>- 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
>- 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

Didn't understand this. Can you elaborate the note to developers please ?

>Comments, suggestions, flames?

View raw message