Thanks Rohit. Had few questions for you. Please find them inline. On 14/02/13 2:58 PM, "Rohit Yadav" <bhais...@apache.org> 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+: 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 :) 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 >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 Didn't understand this. Can you elaborate the note to developers please ? > >Comments, suggestions, flames? > >Regards.
