Open Stack

----- Original Message -----
> From: "Ralf Haferkamp" <rhafer at suse.de>
> To: openstack-dev at lists.openstack.org
> Sent: Wednesday, February 5, 2014 12:47:24 PM
> Subject: Re: [openstack-dev] [Neutron] backporting database migrations	to	stable/havana
> 
> Hi,
> 
> On Tue, Feb 04, 2014 at 12:36:16PM -0500, Miguel Angel Ajo Pelayo wrote:
> > 
> > 
> > Hi Ralf, I see we're on the same boat for this.
> > 
> >    It seems that a database migration introduces complications
> > for future upgrades. It's not an easy path.
> > 
> >    My aim when I started this backport was trying to scale out
> > neutron-server, starting several ones together. But I'm afraid
> > we would find more bugs like this requiring db migrations.
> > 
> >    Have you actually tested running multiple servers in icehouse?,
> > I just didn't have the time, but it's in my roadmap.
> I actually ran into the bug in a single server setup. But that seems to
> happen
> pretty rarely.

Upps, really?, then it's worse than I thought, thank you for this feedback.

> 
> >    If that fixes the problem, may be some heavier approach (like
> > table locking) could be used in the backport, without introducing
> > a new/conflicting migration.
> Hm, there seems to be no clean way to do table locking in sqlalchemy. At
> least I
> didn't find one.

I must admit I didn't yet look at this, if we don't have table locking it's hard to 
think of a proper solution for similar problems.

>  
> > About the DB migration backport problem, the actual problem is:
> [..]
> > 1st step) fix E in icehouse to skip the real unique constraint insertion if
> > it does already exist:
> > 
> > havana   | icehouse
> >          |
> > A<-B<-C<-|--D<-*E*<-F
> >  
> > 2nd step) insert E2 in the middle of B and C to keep the icehouse first
> > reference happy:
> > 
> > havana      | icehouse
> >             |
> > A<-B<-E2<-C<-|--D<-*E*<-F
> > 
> > What do you think?
> I agree, that would likely be the right fix. But as it seems there are some
> (more or less) strict rules about stable backports of migrations (which I
> understand as it can get really tricky). So a solution that doesn't require
> them would probabyl be preferable.


Yes, we must think about something else, but I'm afraid that either we manage
to have table locking, or we will need this DB backport.  

The 2-step process seems correct to me, but we will need approval from the community.
I believe that a bug that breaks agent registration or listing is *bad* enough. But
anyway, until the gate is not stable there are more important things.

I like what the nova guys do, we must definitely make the same at the end
of Icehouse cycle, add a set of empty DB migrations which could be used for
this purpose.