cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: [PROPOSAL] DatabaseCreator: the db deployer, dbv upgrader and db cleaner
Date Thu, 14 Feb 2013 12:13:20 GMT
On Thu, Feb 14, 2013 at 3:36 PM, Nitin Mehta <> wrote:
> 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 ?

I already mentioned the steps, but for details I better show you some
code soon. For 4.1 the tasks are just moving the code and adding an
upgrade path from 40 to 41. For 4.2, the actual work of refactoring
and workflow (deploy, upgrade and clean) will be implemented.

> So major advantage of this tool is for rolling upgrade is it ?

1. Empower admin to make decisions about upgrading workflow:
deployment, upgrade and cleanup
2. Make it easier for a rolling upgrade, leave cleaning up, reverting
upto sysadmin

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

1. In create-schema.sql we define the current version, starting 4.1,
we should only change this file for major version that would be 5.0:
INSERT INTO `version` (`version`, `updated`, `step`) VALUES('4.1.0',
now(), 'Complete');
2. Any changes to schema should be put into an upgrading script in
3. Upgrading logic in cloudstack or DatabaseCreator should upgrade the db
4. The developer who changes schema should be responsible to test the
upgrade sql files, and implement the upgrade path (a class like
Upgrade227to228 or Upgrade400to410 etc.)
5. Make sure the cleaning up works properly: First db is upgraded, sql
changes are applied that are backward compatible with old db, mgmt
server is upgraded and started, when all mgmt servers are upgraded,
the cleaning up code should alter tables etc.

About 5. I'm not sure about the side effects. Alex, if when we will
cleanup and there are running mgmt servers would altering tables etc.
have any side effect. I'm not sure how we should cleanup in future,
what should be the workflow like? Would this mean fixing current
upgrade paths (sqls) so whenever upgrading the db is backward
compatible to old one.


>>Comments, suggestions, flames?

View raw message