[openstack-dev] Work around DB in OpenStack (Oslo, Nova, Cinder, Glance)

Eugene Nikanorov enikanorov at mirantis.com
Wed Jul 3 06:12:46 UTC 2013


Boris, what do you think?

Thanks,
Eugene.


On Tue, Jul 2, 2013 at 9:55 PM, Ben Nemec <openstack at nemebean.com> wrote:

> One small addition I would suggest is a step to remove the unused
> sqlalchemy-migrate code once this is all done.  That's my main concern with
> moving it to Oslo right now.
>
> Also, is this a formal blueprint(s)?  Seems like it should be.
>
> -Ben
>
> On 2013-07-02 12:50, Boris Pavlovic wrote:
>
>>         ##############################**##############################**
>> ###########
>>  Goal
>>
>>         ##############################**##############################**
>> ###########
>>
>> We should fix work with DB, unify it in all projects and use oslo code
>> for all common things.
>>
>> In more words:
>>
>> DB API
>>
>>  *) Fully cover by tests.
>>
>>  *) Run tests against all backends (now they are runed only against
>> sqlite).
>>
>>  *) Unique constraints (instead of select + insert)
>>  a) Provide unique constraints.
>>  b) Add missing unique constraints.
>>
>>  *) DB Archiving
>>  a) create shadow tables
>>  b) add tests that checks that shadow and main table are synced.
>>  c) add code that work with shadow tables.
>>
>>  *) DB API performance optimization
>>  a) Remove unused joins.
>>  b) 1 query instead of N (where it is possible).
>>  c) Add methods that could improve performance.
>>  d) Drop unused methods.
>>
>>  *) DB reconnect
>>  a) Don't break huge task if we lost connection for a moment. just
>> retry DB query.
>>
>>  *) DB Session cleanup
>>  a) do not use session parameter in public DB API methods.
>>  b) fix places where we are doing N queries in N transactions instead
>> of 1.
>>  c) get only data that is used (e.g. len(query.all()) =>
>> query.count()).
>>
>> ----
>>
>> DB Migrations
>>
>>  *) Test DB Migrations against all backends and real data.
>>
>>  *) Fix: DB schemas after Migrations should be same in different
>> backends
>>
>>  *) Fix: hidden bugs, that are caused by wrong migrations:
>>  a) fix indexes. e.g. 152 migration in Nova drop all Indexes that has
>> deleted column
>>  b) fix wrong types
>>  c) drop unused tables
>>
>>  *) Switch from sqlalchemy-migrate to something that is not death
>> (e.g. alembic).
>>
>> ----
>>
>> DB Models
>>
>>  *) Fix: Schema that is created by Models should be the same as after
>> migrations.
>>
>>  *) Fix: Unit tests should be runed on DB that was created by Models
>> not migrations.
>>
>>  *) Add test that checks that Models are synced with migrations.
>>
>> ----
>>
>> Oslo Code
>>
>>  *) Base Sqlalchemy Models.
>>
>>  *) Work around engine and session.
>>
>>  *) SqlAlchemy Utils - that helps us with migrations and tests.
>>
>>  *) Test migrations Base.
>>
>>  *) Use common test wrapper that allows us to run tests on different
>> backends.
>>
>>         ##############################**##############################**
>> ###########
>>  Implementation
>>
>>         ##############################**##############################**
>> ###########
>>
>>  This is really really huge task. And we are almost done with Nova=).
>>
>>  In OpenStack for such work there is only one approach ("baby steps"
>> development deriven). So we are making tons of patches that could be
>> easy reviewed. But there is also minuses in such approach. It is
>> pretty hard to track work on high level. And sometimes there are
>> misunderstand.
>>
>>  For example with oslo code. In few words at this moment we would like
>> to add (for some time) in oslo monkey patching for sqlalchemy-migrate.
>> And I got reasonable question from Doug Hellmann. Why? I answer
>> because of our "baby steps". But if you don't have a list of baby
>> steps it is pretty hard to understand why our baby steps need this
>> thing. And why we don't switch to alembic firstly. So I would like to
>> describe our Road Map and write list of "baby steps".
>>
>> -------
>>
>> OSLO
>>
>>  *) (Merged) Base code for Models and sqlalchemy engine (session)
>>
>>  *) (On review) Sqlalchemy utils that are used to:
>>  1. Fix bugs in sqlalchemy-migrate
>>  2. Base code for migrations that provides Unique Constraints.
>>  3. Utils for db.archiving helps us to create and check shadow tables.
>>
>>  *) (On review) Testtools wrapper
>>  We should have only one testtool wrapper in all projects. And this is
>> the one of base steps in task of running tests against all backends.
>>
>>  *) (On review) Test migrations base
>>  Base classes that provides us to test our migrations against all
>> backends on real data
>>
>>  *) (On review, not finished yet) DB Reconnect.
>>
>>  *) (Not finished) Test that checks that schemas and models are synced
>>
>> -------
>>
>> ${PROJECT_NAME}
>>
>> In different projects we could work absolutely simultaneously, and
>> first candidates are Glance and Cinder. But inside project we could
>> also work simultaneously. Here is the workflow:
>>
>>  1) (SYNC) Use base code for Models and sqlalchemy engines (from oslo)
>>
>>  2) (SYNC) Use test migrations base (from oslo)
>>
>>  3) (SYNC) Use SqlAlchemy utils (from oslo)
>>
>>  4) (1 patch) Switch to OSLO DB code
>>
>>  5) (1 patch) Remove ported test migrations
>>
>>  6) (1 Migration) Provide unique constraints (change type of "deleted"
>> column)
>>
>>  7) (1 Migration) Add shadow tables
>>  a) Create shadow tables
>>  b) Add test that checks that they are synced always
>>
>>  8) (N Migrations) UniqueConstraint/Session/**Optimization workflow:
>>  a) (1 patch) Add/Improve/Refactor tests for part of api (that is
>> connected with model)
>>  b) (1 patch) Fix session
>>  c) (1 patch) Optimize method
>>  d) if required (1 Migration) Add missing Unique Constraints.
>>
>>  9) (M Migrations) Sync Models with DB schemas (almost independent
>> from 8)
>>  a) (K pathces) Sync Models with MySQL Migrations
>>  (because they are different in different backneds)
>>  b) (Fix, L migrations) Fix migrations, that have bugs (e.g. 152
>> migraiton in Nova, drops all
>>  Indexes that have 'deleted' column).
>>  c) Add test for MySql
>>  d) (Fix, 2 migrations) Sync other backends schemas with MySql schema
>>  e) Add test for SQLite and Psql
>>  f) Rethink our models:
>>  *) Improve Indexes
>>  *) Use Enum where it is required
>>  *) Fix bugs if there are.
>>  *) Add missing default values in schema.
>>
>> 10) Test should be runed on schema that is created from Models, not
>> migrations (depend on 9)
>>
>> 11) Use alembic (or something else) instead of sqlalchemy-migrate
>> (after 9.e. it will be safe
>>  a) make test migrations independent from sqlalchemy-migrate
>>  b) (If alembic) Provide work with sqlite.
>>  c) Replace all migrations
>>
>> Main part of work is in 7, 8 and 10 points.
>>
>>         ##############################**##############################**
>> ###########
>>  Answer for Doug's question
>>          ##############################**##############################**
>> ###########
>>
>> Question:
>>  Why we should put in oslo slqlalchemy-migrate monkey patches, when we
>> are planing to switch to alembic?
>>
>> Answer:
>>  If we don't put in oslo sqlalchemy-migrate monkey patches. We won't
>> be able to work on 7 point at all until 8 and 10 points will be
>> implemented in every project. Also work around 8 point is not
>> finished, so we are not able to implement 10 points in any of project.
>> So this blocks almost all work in all projects. I think that these
>> 100-200 lines of code are not so big price for saving few cycles of
>> time.
>>
>>         ##############################**##############################**
>> ###########
>>  Current progress
>>
>>         ##############################**##############################**
>> ###########
>>
>> Nova
>>
>>  *) 1,4,6,7 - fully finished
>>
>>  *) 2,3,5 - waiting for oslo, but pretty simple to sync it
>>
>>  *) 8 - almost finished
>>  a) Few patched around tests (on review)
>>  b) 9 patches that add UniqueConstraints (on review) and few missing
>>  c) Few patches about session (on review) and few missing
>>
>>  *) 9 - tons of patches that syncs models with MySql on review. Also
>> we are working around tests that checks that schemas that are crated
>> by models and migrations are same. So it will be a lot of work here.
>>
>>  *) 10 - pretty simple (blocked by 9)
>>
>>  *) 11 - tons of work, candidate for I cycle.
>>
>>  *) Also here is work around run test on all backends but it is not
>> finished yet.
>>
>>  -------
>>
>> Cinder
>>
>>  *) 1,4 - finished
>>
>>  *) Some work around 8 (sessions and tests)
>>
>>  *) Other things are blocked by oslo
>>
>> -------
>>
>> Glance
>>
>>  *) 1 - finished
>>
>>  *) 4 - working on it
>>
>> Best regards,
>>
>> Boris Pavlović
>>
>> (irc boris-42)
>>
>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130703/b17e5d8b/attachment.html>


More information about the OpenStack-dev mailing list