incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-pick commits from master
Date Wed, 20 Mar 2013 21:22:59 GMT
John,

The code was in before deadline.  I think you're looking at a commit where Rohit tried to
fix a problem with the developer deploy in the pom.xml.  I had previously thought even though
the developer deploy had problems, the production deploy was actually working.  Turns out
it wasn't.

--Alex

> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com]
> Sent: Wednesday, March 20, 2013 1:32 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires cherry-
> pick commits from master
> 
> Alex,
> 
> Given that we are 3 business days to the RC1 deadline, it seems to me that
> we should pursue to lowest risk path possible.  To my mind, that would be
> reverting to the 4.0 behavior.  Is there a way to revert to the previous
> behavior for 4.1 and defer the entire enhancement to 4.2?
> 
> Based on the mailing list discussion, it appears that this change was
> introduced after the 31 Jan 2013 code freeze.  If my understanding of the
> history correct, I think there is broader issue we need to work out as
> community -- how/why did this feature get merged post-freeze?
> 
> Thanks,
> -John
> 
> On Mar 20, 2013, at 4:24 PM, Alex Huang <Alex.Huang@citrix.com> wrote:
> 
> > Hi everyone,
> >
> > We had a discussion on irc.
> >
> > To implement something intermediary will be around the same effort as
> finishing the job and there are various reasons why just running the create-
> schema.sql and update*.sql is not enough.  So we should just decide on
> finishing the job in 4.1 or document the behavior.
> >
> > Any input on which way we should take.
> >
> > The engineer in me says just finish the job.  It's obviously working in dev
> setup on master so the risk of this introducing bugs is very low.  If someone
> knows why it's difficult to change in cloud-setup-databases script, please
> speak up.
> >
> > --Alex
> >
> >> -----Original Message-----
> >> From: Chip Childers [mailto:chip.childers@sungard.com]
> >> Sent: Wednesday, March 20, 2013 12:39 PM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: Re: CLOUDSTACK-1747: fresh deploydb bug in 4.1 requires
> >> cherry- pick commits from master
> >>
> >> On Wed, Mar 20, 2013 at 11:43:30AM -0700, Min Chen wrote:
> >>> Chip,
> >>>
> >>> 	By reading Rohit's email and wiki, I understood current situation
> >>> on this issue. Unlike I previously understood, this DB issue not
> >>> only happens on dev environment, but also happens on QA/production
> >> environment as well.
> >>> And this introduces a different behavior in 4.1 from previous 4.1 release.
> >>> The commits mentioned in this bug will only fix dev environment, but
> >>> to fix QA/productioin env, we need that pending feature (making
> >>> cloud-setup-database use DatabaseCreator) to be done. We need
> >>> community concensus whether we want to fix it in 4.1 or 4.2. Based
> >>> on timeline, it may be wise to fix it in 4.2 and create a JIRA
> >>> ticket to track this. If so, I still think that we need to file a
> >>> doc bug to document this change in 4.1.
> >>
> >> Is there no option for us to set the correct version for 4.1 during
> >> an upgrade / fresh install, based on the current approach used in the 4.1
> branch?


Mime
View raw message