Hello everyone!
I would like to try to solve this problem. I registered blueprint on this
topic
https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrationsand
I'm going to experiment with options to solve this. I'm welcome any
suggestions and ready to talk about it via IRC
Thanks Anna.
I've been following the issue so far, but I am happy to hand it over to you.
I think the problem assessment is complete, but if you have more questions
ping me on IRC.
Regarding the solution, I think we already have a fairly wide consensus on
the approach.
There are however a few
On Tue, Apr 15, 2014 at 7:03 AM, Salvatore Orlando sorla...@nicira.com wrote:
Thanks Anna.
I've been following the issue so far, but I am happy to hand it over to you.
I think the problem assessment is complete, but if you have more questions
ping me on IRC.
Regarding the solution, I think
I know alembic is designed to be global, but could we extend it to track
multiple histories for a given database. In other words, various branches for
different namespaces on a single database. Would this feature ameliorate the
issues?
Amir
On Apr 15, 2014, at 8:24 AM, Kyle Mestery
On Apr 14, 2014, at 11:54 AM, Salvatore Orlando
sorla...@nicira.commailto:sorla...@nicira.com wrote:
1) Specify that all migrations must run for every plugin (*) unless they are
really introducing schemas which are specific to a particular technology (such
as uuid mappings between neutron
This is a rather long post. However the gist of it is that Neutron
migrations are failing to correctly perform database upgrades when service
plugins are involved, and this probably means the conditional migration
path we designed for the Grizzly release is proving not robust enough when
dealing
On Mon, Apr 14, 2014 at 10:54 AM, Salvatore Orlando sorla...@nicira.com wrote:
Resending with [Neutron] tag.
Salvatore
On 14 April 2014 16:00, Salvatore Orlando sorla...@nicira.com wrote:
This is a rather long post. However the gist of it is that Neutron
migrations are failing to
On 04/14/2014 12:09 PM, Kyle Mestery wrote:
On Mon, Apr 14, 2014 at 10:54 AM, Salvatore Orlando sorla...@nicira.com
wrote:
snip
The system could be made smarter by storing also a list of known
migrations, including whether they were executed or skipped.
Summarising, in my opinion the
Hi Salvatore,
The described problem could be even worse if vendor drivers are considered.
Doesn't #1 require that all DB tables are named differently? Otherwise it
seems that user can't be sure in DB schema even if all tables are present.
I think the big part of the problem is that we need to
On 14 April 2014 17:27, Sean Dague s...@dague.net wrote:
On 04/14/2014 12:09 PM, Kyle Mestery wrote:
On Mon, Apr 14, 2014 at 10:54 AM, Salvatore Orlando sorla...@nicira.com
wrote:
snip
The system could be made smarter by storing also a list of known
migrations, including whether they
On 04/14/2014 12:46 PM, Eugene Nikanorov wrote:
Hi Salvatore,
The described problem could be even worse if vendor drivers are considered.
Doesn't #1 require that all DB tables are named differently? Otherwise
it seems that user can't be sure in DB schema even if all tables are
present.
I
11 matches
Mail list logo
