The whole upgrade process can probably be divided into a few parts: 1. Apply new schema 2. Data Migration (this is the stored proc updates if you will) 3. Upgrade of system scripts and templates 4. Phased service (agent/management) shutdown and java updates.
As a first step if 1. and 2. can be delinked from 3. and 4. I'd be a happy admin. But having java v1 along side java v2 while the DB has been switched over to the new version is going to involve more work. It would have to start with good guidelines on how not to code with a db-version/schema in mind. I also felt that writing stored procs and complex SQL can be a learning curve for java devs and the tools I mentioned can help break that dependency by moving to XML based database configuration that can be version controlled. But I'm not sure of adoption of such tools into ops teams like the one you mention - ops, db and app - separated. I haven't explored flyway though. The upgrade process needs a revisit and cleaning up and should be considered in the upcoming releases. On Tue, Aug 27, 2013 at 10:21:07PM -0700, Darren Shepherd wrote: > Custom java code to manage the database is every DBAs worse > nightmare. I'd be very very interested into moving to an off the > shelf DB migration tool. I'd recommend flyway given the fact that > CloudStack only supports mysql and is very SQL DDL oriented as it > stands. > > I'll probably look into this a bit later. I know personally if I > had to deploy DB updates this way to production, I would not be a > happy admin. > > If you find you have to do crazy weird DML for an upgrade that's > only possible in java I'd probably say your doing something wrong. > Worst case scenario create a proc that does the update and then drop > the proc. You need to have all migrations in SQL files such that a > DBA can review them. > > For upgrades you should be able to keep java code v1 running and run > the upgrade to DB v2. Then deploy java v2 code. Having to shutdown > and big bang do DB and java is too risky of a deployment. Many many > companies separate application and DB to completely different teams. > > Not to mention runtime DB user has DML rights. Ever tried to pass > an audit with stuff like that, yikes. > > Darren > > On Aug 27, 2013, at 10:00 PM, Prasanna Santhanam <t...@apache.org> wrote: > > > On Tue, Aug 27, 2013 at 04:48:02PM -0700, Darren Shepherd wrote: > >> It seems like on startup of the management server > >> DatabaseUpgradeChecker runs and upgrades the database performing DDL > >> and DML. Is there a way to upgrade the database that doesn't > >> include starting the management server? > > > > This would be a *massive* boon to all the upgrade testing. Running the > > upgrade without having the server to be up using a db versioning tool > > like liquibase/dbmaintain. This had come up before and I remember > > talking to Alex who had explored such tools and found them unsuitable > > at the time. > > > > There are parts of the upgrade that alter database rows (IIRC) which > > is done using java code. These run only when the server is running and > > cause this coupling. These are file that start Upgrade*.java > > > > -- > > Prasanna., > > > > ------------------------ > > Powered by BigRock.com > > -- Prasanna., ------------------------ Powered by BigRock.com
