Hi all, I've been looking at the way DB related code (SQL scripts and Java classes) are updated and what is the impact of those updates on a live cloudstack DB. By the way, my intention is to support a per-commit DB upgrade of a running system.
Anyway, I completely agree that sending an email warning people about changes that can potentially break running environments is a good thing, and can save a lot of time and headaches. I also like the idea of Rajani of using tools to help in the DB migration process. However, I would like to put forward another idea: what about making sure that the changes to the DB (schema and data) are always incremental? I mean, once a SQL statement (say A) is added to a script it could be kept as is, and subsequent modifications cloud be made via new statements (say B), instead of adapting A. This would allow people to upgrade their databases to the point they ran statement A, and afterwards upgrade it again to the point they ran statement B. The same principle could also be applied to the Java classes that do data migration, but maybe there it might be a bit more involved. Cheers, Miguel -----Original Message----- From: Koushik Das [mailto:koushik....@citrix.com] Sent: donderdag 6 maart 2014 8:25 To: <dev@cloudstack.apache.org> Subject: Re: [DISCUSS] Checking in code that will break others' environments Before doing a git pull, I generally check the sql schema changes and run the delta manually on my existing setup. In most of the cases that works for me without having to redeploy the db. -Koushik On 06-Mar-2014, at 11:43 AM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > Yeah, I definitely just meant a "heads up" during development if you > are going to change something that will break other people's > environments who update. If these people know in advance, they may > choose to postpone an update until they are at a better point. > > > On Wed, Mar 5, 2014 at 11:01 PM, Rajani Karuturi > <rajani.karut...@citrix.com >> wrote: > >> Across versions db migration is taken care. I think this is bound to >> occur while working on a release, if multiple people work on the same >> branch with different work-in-progress features. >> >> Could we move to flyway or liquibase which can take care of db >> versioning and migration? >> >> >> ~Rajani >> >> >> >> On 06-Mar-2014, at 2:08 am, Mike Tutkowski >> <mike.tutkow...@solidfire.com> >> wrote: >> >>> Yeah, in this case, I'm not referring to erroneous code that breaks >>> a person's environment (since hopefully the person wouldn't have >>> knowingly checked in such code), but rather, say, DB-type changes >>> that improve the system, but break current setups. >>> >>> Just a heads-up e-mail with some easily identifiable tag. >>> >>> Can anyone think of a good tag for this? It's not always DB related, >>> so >> we >>> might want the tag to be more general. >>> >>> >>> On Wed, Mar 5, 2014 at 1:28 PM, Ian Duffy <i...@ianduffy.ie> wrote: >>> >>>> +1 to this. >>>> >>>> Having the build suddenly break due to a git pull has been very >> annoying! >>>> I usually end up searching through the commit log and doing a >>>> resets until I find a commit where it works. Then waiting awhile >>>> until I do a git pull again and hoping the code was fixed. >>>> >>>> On 5 March 2014 20:19, Mike Tutkowski >>>> <mike.tutkow...@solidfire.com> >>>> wrote: >>>>> Hi, >>>>> >>>>> I encountered a bit of a problem this morning and thought I would >>>>> bring >>>> it >>>>> up for discussion. >>>>> >>>>> If we already have a policy around this, please let me know. >>>>> >>>>> So, I fetched the latest and rebased my local 4.4 development >>>>> branch on >>>> top >>>>> of master. This all went just fine. >>>>> >>>>> When I rebuilt and re-started the CS Management Server, I soon >> realized I >>>>> could no longer log in from the GUI. >>>>> >>>>> As it turns out, the DB schema had been updated and so my database >>>>> was >>>> out >>>>> of date. The code was querying for fields that didn't exist in my DB. >>>>> >>>>> As far as I know, the easiest way to get around this is to destroy >>>>> my current cloud, run the script to re-build my database, then >>>>> re-create >> my >>>>> cloud, which is somewhat time consuming. >>>>> >>>>> Do we have a process in place currently in which we ask those who >>>>> make >>>> such >>>>> changes to send out a notification e-mail to dev@ to give people a >>>> heads up >>>>> that updating will lead to such issues? On previous projects, we >>>>> would >>>> send >>>>> out an e-mail and then people could be aware to only update if >>>>> they >> were >>>>> prepared for such re-work. >>>>> >>>>> To be clear here, I'm not meaning to pick on anyone in >> particular...this >>>>> has happened several times over the course of my CloudStack >>>>> development >>>> and >>>>> I expect that I, too, have checked in such code (without sending >>>>> out a relevant e-mail) that lead people to have to perform such a >>>>> complete re-build action un-expectedly. >>>>> >>>>> What do people think about this? Maybe we should just add an >>>>> e-mail tag >>>> or >>>>> something and point people to the relevant commit? >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> *Mike Tutkowski* >>>>> *Senior CloudStack Developer, SolidFire Inc.* >>>>> e: mike.tutkow...@solidfire.com >>>>> o: 303.746.7302 >>>>> Advancing the way the world uses the >>>>> cloud<http://solidfire.com/solution/overview/?video=play> >>>>> *(tm)* >>>> >>> >>> >>> >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkow...@solidfire.com >>> o: 303.746.7302 >>> Advancing the way the world uses the >>> cloud<http://solidfire.com/solution/overview/?video=play> >>> *(tm)* >> >> > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *(tm)*
