[openstack-dev] [Solum] Some initial code copying for db/migration

Russell Bryant rbryant at redhat.com
Fri Nov 1 16:30:19 UTC 2013

On 11/01/2013 11:14 AM, Clayton Coleman wrote:
> ----- Original Message -----
>> Noorul Islam K M <noorul at noorul.com> writes:
>>> Adrian Otto <adrian.otto at rackspace.com> writes:
>>>> Team,
>>>> Our StackForge code repo is open, so you may begin submitting code for
>>>> review. For those new to the process, I made a will page with links to
>>>> the repo and information about how to contribute:
>>>> https://wiki.openstack.org/wiki/Solum/Contributing
>>> 1. .gitreview file is missing, so I submitted a patch
>>> https://review.openstack.org/#/c/54877
> Once all the gitreview stuff is cleaned up I was going to do some purely mechanical additions.
> I heard a few +1 for sqlalchemy with the standard OpenStack abstraction:
> solum/db/api.py
>   manager abstraction for db calls
> solum/db/sqlalchemy/api.py
>   sqlalchemy implementation

I wouldn't just copy this layout, personally.

We should look at getting some of the nova object work into
oslo-incubator.  It provides a nice object model to abstract away the
database API details.  You really don't want to be returning sqlalchemy
models to the rest of the code base if you can get away with it.

If we were starting the Nova database integration work from scractch
today, I'm not sure we'd have db.api and db.sqlalchemy.api.  It seems
like it would make more sense to add the db.api equivalents to our
objects, and sub-class them to add specific database support.

> I was also going to throw in migrate as a dependency and put in the glue code for that based on common use from ironic/trove/heat.  That'll pull in a few openstack common and config settings.  Finally, was going to add a solum-dbsync command a la the aforementioned projects.  No schema will be added.

I also would not use migrate.  sqlalchemy-migrate is a dead upstream and
we (OpenStack) have had to inherit it.  For new projects, you should use
alembic.  That's actively developed and maintained.  Other OpenStack
projects are either already using it, or making plans to move to it.

Russell Bryant

More information about the OpenStack-dev mailing list