Open Stack

----- Original Message -----
> From: "Miguel Angel Ajo Pelayo" <mangelajo at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Tuesday, February 4, 2014 6:36:16 PM
> Subject: Re: [openstack-dev] [Neutron] backporting database migrations	to	stable/havana
> 
> 
> 
> 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.
> 
>    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.
> 
> 
> 
> About the DB migration backport problem, the actual problem is:
> 
> you have migrations A,B,C,D,E,F and cross version boundaries |, them
> migrations
> are a linked list.
> 
> havana   | icehouse
>          |
> A<-B<-C<-|-D<-E<-F
> 
> the problem is that if you want to bring E back, you have to fix E, but the
> first
> migration on the next release keeps pointing to C
> 
> havana     | icehouse
>            |
> A<-B<-C<-E |
>         \--|--D<-E<-F
> 
> 
> at this moment in our backport, we didn't even fix E, so it's worse... E
> points
> to D that it doesn't even exist yet
> 
> you can think of fixing this tree, by putting E in the middle of B and C, but
> then E is replicated, and F points to an E that exists twice.
> 
> 
> and an almost good fix would be:
> 
> havana     | icehouse
>            |
> A<-B<-E2<-C|--D<-E<-F
> 
> but then the code in E will fail because the unique constraint was already
> applied, so in
> 2 steps we could do (if I'm not wrong....)
> 
> 
> 
> 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<-E<-C<-|--D<-*E*<-F
> 
> 

Sorry, I had a typo in this last ascii figure: (missing 2 in the E)

 havana      | icehouse
             |
A<-B<-E2<-C<-|--D<-*E*<-F


> 
> What do you think?
> 
> 
> ----- Original Message -----
> > From: "Ralf Haferkamp" <rhafer at suse.de>
> > To: openstack-dev at lists.openstack.org
> > Sent: Tuesday, February 4, 2014 4:02:36 PM
> > Subject: [openstack-dev] [Neutron] backporting database migrations to
> > 	stable/havana
> > 
> > Hi,
> > 
> > I am currently trying to backport the fix for
> > https://launchpad.net/bugs/1254246 to stable/havana. The current state of
> > that
> > is here: https://review.openstack.org/#/c/68929/
> > 
> > However, the fix requires a database migration to be applied (to add a
> > unique
> > constraint to the agents table). And the current fix linked above will
> > AFAIK
> > break havana->icehouse migrations. So I wonder what would be the correct
> > way
> > to
> > do backport database migrations in neutron using alembic? Is there even a
> > correct way, or are backports of database migrations a no go?
> > 
> > --
> > regards,
> >     Ralf
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>