Hi Daan, Is there anything stopping you from scripting the configuration of your CloudStack testbed? E.g. with Marvin or CloudMonkey
DL > -----Original Message----- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: 06 March 2014 09:53 > To: dev > Cc: Daan Hoogland > Subject: Re: [DISCUSS] Checking in code that will break others' environments > > I totally agree with the incremental approach. I am a fascist at time because > i > would even want people to add downgrade scripts to any db change they > make. Having them not adjust their sql is a good first step, though. > > On Thu, Mar 6, 2014 at 10:43 AM, Miguel Ferreira > <mferre...@schubergphilis.com> wrote: > > 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)* > > > > > > -- > Daan
