Re: [openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database
> On Dec 5, 2014, at 3:14 PM, Matt Riedemann 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
Re: [openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database
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
On Fri, Dec 05, 2014, 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. 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
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
