Re: [openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database

2014-12-05 Thread Matt Riedemann



On 12/5/2014 1:45 PM, Andrew Laski wrote:

The cells v2 effort is going to be introducing a new database into
Nova.  This has been an opportunity to rethink and approach a few things
differently, including how we should handle migrations. There have been
discussions for a long time now about switching over to alembic for
migrations so I want to ask, should we start using alembic from the
start for this new database?

The question was first raised by Dan Smith on
https://review.openstack.org/#/c/135424/

I do have some concern about having two databases managed in two
different ways, but if the details are well hidden behind a nova-manage
command I'm not sure it will actually matter in practice.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I don't have experience with Alembic but I'd think we should use Alembic 
for the new database unless there is a compelling reason not to. Maybe 
we need Mike Bayer (or other oslo.db people) to give us an idea of what 
kinds of problems we might have with managing two databases with two 
different migration schemes.


But the last part you said is key for me, if we can abstract it well 
then hopefully it's not very painful.


--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database

2014-12-05 Thread Johannes Erdfelt
On Fri, Dec 05, 2014, Andrew Laski andrew.la...@rackspace.com wrote:
 The cells v2 effort is going to be introducing a new database into
 Nova.  This has been an opportunity to rethink and approach a few
 things differently, including how we should handle migrations. There
 have been discussions for a long time now about switching over to
 alembic for migrations so I want to ask, should we start using
 alembic from the start for this new database?
 
 The question was first raised by Dan Smith on
 https://review.openstack.org/#/c/135424/
 
 I do have some concern about having two databases managed in two
 different ways, but if the details are well hidden behind a
 nova-manage command I'm not sure it will actually matter in
 practice.

This would be a good time for people to review my proposed spec:

https://review.openstack.org/#/c/102545/

Not only does it help operators but it also helps developers since all
they would need to do in the future is update the model and DDL
statements are generated based on comparing the running schema with the
model.

BTW, it uses Alembic under the hood for most of the heavy lifting.

JE


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database

2014-12-05 Thread Sylvain Bauza


Le 05/12/2014 21:14, Matt Riedemann a écrit :



On 12/5/2014 1:45 PM, Andrew Laski wrote:

The cells v2 effort is going to be introducing a new database into
Nova.  This has been an opportunity to rethink and approach a few things
differently, including how we should handle migrations. There have been
discussions for a long time now about switching over to alembic for
migrations so I want to ask, should we start using alembic from the
start for this new database?

The question was first raised by Dan Smith on
https://review.openstack.org/#/c/135424/

I do have some concern about having two databases managed in two
different ways, but if the details are well hidden behind a nova-manage
command I'm not sure it will actually matter in practice.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I don't have experience with Alembic but I'd think we should use 
Alembic for the new database unless there is a compelling reason not 
to. Maybe we need Mike Bayer (or other oslo.db people) to give us an 
idea of what kinds of problems we might have with managing two 
databases with two different migration schemes.


But the last part you said is key for me, if we can abstract it well 
then hopefully it's not very painful.





I had some experience with Alembic in a previous Stackforge project and 
I'm definitely +1 on using it for the Cells V2 database.


We can just provide a nova-manage cell-db service that would facade the 
migration backend, whatever it is.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database

2014-12-05 Thread Mike Bayer

 On Dec 5, 2014, at 3:14 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:
 
 
 
 On 12/5/2014 1:45 PM, Andrew Laski wrote:
 The cells v2 effort is going to be introducing a new database into
 Nova.  This has been an opportunity to rethink and approach a few things
 differently, including how we should handle migrations. There have been
 discussions for a long time now about switching over to alembic for
 migrations so I want to ask, should we start using alembic from the
 start for this new database?
 
 The question was first raised by Dan Smith on
 https://review.openstack.org/#/c/135424/
 
 I do have some concern about having two databases managed in two
 different ways, but if the details are well hidden behind a nova-manage
 command I'm not sure it will actually matter in practice.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 I don't have experience with Alembic but I'd think we should use Alembic for 
 the new database unless there is a compelling reason not to. Maybe we need 
 Mike Bayer (or other oslo.db people) to give us an idea of what kinds of 
 problems we might have with managing two databases with two different 
 migration schemes.
 
 But the last part you said is key for me, if we can abstract it well then 
 hopefully it's not very painful.

sqlalchemy-migrate doesn’t really have a dedicated maintainer anymore, AFAICT.  
It’s pretty much on stackforge life support.   So while the issue of merging 
together a project with migrate and alembic at the same time seems to be 
something for which there are some complexity and some competing ideas (I have 
one that’s pretty fancy, but I haven’t spec’ed or implemented it yet, so for 
now there are “wrappers” that run both), it sort of has to happen regardless.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev