Open Stack

On 5/25/15 10:35 PM, Armando M. wrote:
>
> On 25 May 2015 at 09:46, Mike Bayer <mbayer at redhat.com 
> <mailto:mbayer at redhat.com>> wrote:
>
>
>
>     On 5/25/15 12:34 PM, Armando M. wrote:
>>
>>
>>
>>     One thing I would like to point out is that in this cycle we'll
>>     be working extensively in this area to make the very task you are
>>     working on easier to deal with, and better documented. This will
>>     fall under the umbrella of the blueprint [1].
>>
>>     HTH
>>     Armando
>>
>>     [1]
>>     https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition
>
>     took a look at https://review.openstack.org/#/c/134680/17, can I
>     have some clarification on what "currently alembic requires extra
>     work to support multiple db migration paths onto a single
>     database"?   Want to make sure you're aware that Alembic supports
>     this fully (and my job has been to try to get Openstack projects
>     to notice); see
>     http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases.
>
>
> The wording might be confusing, my bad.
>
> What I intended there was that neutron's logic to handle alembic 
> migrations required some work in order to simplify the support of 
> out-of-tree DB migrations. Past experiences, like the one that 
> triggered this thread, have shown that we can improve neutron's 
> tooling (neutron-db-manage), as well as documentation.
I wonder if there is some way that out-of-tree migrations can still take 
place within the migration stream as a whole.  As those external trees 
can be built assuming the central Neutron migration series as a 
dependency, if their directories are added to the "version_locations" 
collection before the alembic command line runner invokes the migration, 
they will form part of the total migration setup for the database.   
This was one use case I had in mind when building out this feature.   
The command line runner is extensible so a runtime extension to 
configuration is feasible.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150526/fbd8ace5/attachment.html>