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
What do you think?
----- Original Message -----
> From: "Ralf Haferkamp" <[email protected]>
> To: [email protected]
> 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
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
