On Apr 14, 2014, at 11:54 AM, Salvatore Orlando
mailto: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 and backed)
This ap
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
mailto:mes
On Tue, Apr 15, 2014 at 7:03 AM, Salvatore Orlando 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 we already ha
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 det
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 (akamysh
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.
On 14 April 2014 17:27, Sean Dague wrote:
> On 04/14/2014 12:09 PM, Kyle Mestery wrote:
> > On Mon, Apr 14, 2014 at 10:54 AM, Salvatore Orlando
> wrote:
>
> >>> The system could be made smarter by storing also a list of "known"
> >>> migrations, including whether they were executed or skipped.
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 sup
On 04/14/2014 12:09 PM, Kyle Mestery wrote:
> On Mon, Apr 14, 2014 at 10:54 AM, Salvatore Orlando
> wrote:
>>> 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 approach #2 is
On Mon, Apr 14, 2014 at 10:54 AM, Salvatore Orlando wrote:
> Resending with [Neutron] tag.
>
> Salvatore
>
>
> On 14 April 2014 16:00, Salvatore Orlando wrote:
>>
>> This is a rather long post. However the gist of it is that Neutron
>> migrations are failing to correctly perform database upgrades
Resending with [Neutron] tag.
Salvatore
On 14 April 2014 16:00, Salvatore Orlando wrote:
> 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 conditi
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 wi
12 matches
Mail list logo
