Open Stack

Vish,

Schema comparator could be written as on one simple bash script. So it
won't take a lot of time to run it every time.
But all complex work around migrations will be much simpler in first
approach (and there will be at least 2 times less work at all).

Also we shouldn't wait anything and could start work on it now (replacing
one by one migration)

Best regards,
Boris Pavlovic





On Wed, Jul 17, 2013 at 1:06 AM, Vishvananda Ishaya
<vishvananda at gmail.com>wrote:

>
> On Jul 16, 2013, at 11:48 AM, Boris Pavlovic <boris at pavlovic.me> wrote:
>
> David,
>
> 1. Dan Prince thing is equal useful and can help in both cases
>
> 2. We are not able to block all openstack for an half year to implement
> your plan
>
> 3. We are able only to convert only grizzly migrations not havana (because
> our customers should be able to switch from grizzly to havana)
>
> 4. We don't need to wait to make SQLAlchemy-migrate deprecated because
> script that allows in same way to use alembic and migrate is almost ready.
>
> 5. I just don't understand, we are spending tons of times to fix and unify
> work around DB in whole openstack. It is pretty complex and large task. And
> we should choose the way that is simpler:
>
> Our approach:
> 1) Migrate N migrations to alembic step by step (this work is pretty
> simple) with tons of tests + Dan Prince method
>
> Your approach:
> 1) Migrate N migrations to one big migrations (it is much more complex
> then our 1 step)
> 2) Replace one really huge migration to one Really huge migration in
> alembic (it is also more complex then our 1 step)
>
> So instead on doing 1 long but simple step we are doing 2 complex. Could
> you explain me why?
>
>
> The testing is far simpler in the second approach. You only have to dump
> the output of the database between before 1, after 1, and after 2 and make
> sure that it is the same in each case. That means three versions that must
> be the same. In The first approach you have to verify that the database is
> exactly the same after each migration set, potentially 100 versions that
> must be in sync.
>
> Vish
>
>
> Best regards,
> Boris Pavlovic
>
>
> On Tue, Jul 16, 2013 at 10:16 PM, David Ripton <dripton at redhat.com> wrote:
>
>> On 07/16/2013 01:58 PM, Boris Pavlovic wrote:
>>
>>  There is no "magic" and we have only 2 ways to end up with this problems
>>> and bugs that could be caused by "manually" migrations merging and tons
>>> of bugs in sqlalchemy-migrate.
>>>
>>> 1) step by step (openstack method)
>>>    There are special tests "test_migrations" that runs migrations on
>>> real data against all backends. So we should:
>>>
>>>    a) improve this tests to checks all behaviors // there is a lot of
>>> hidden bugs
>>>    b) replace migration (only one small migration) to alembic
>>>    c) check that in all backends we made the same changes in schema
>>>    d) Merge all old migrations in one using alembic (automatically).
>>>    So it could be done in safe way.
>>>
>>> 2.a) huge 2 steps
>>>    1. Merge all migrations in one huge manually (drop all tests in test
>>> migrations)
>>>        e.g. In Nova was patch https://review.openstack.org/#**/c/35748/<https://review.openstack.org/#/c/35748/>
>>>        I don't believe that there are no mistakes in this migration, and
>>> nobody is able to check it. // because of tons of hidden bugs in old
>>> migrations and sqla-migrate.
>>>    2. Replace this migration in Alembic
>>>         I don't believe that there will be way to check that there is no
>>> bugs
>>>
>>> 2.b) suicide mode (1 big step)
>>>    Merge and switch in one step=)
>>>
>>
>> We have compacted migrations before, and there's a test document for how
>> to verify that the big migration has exactly the same output as the series
>> of small migrations.  See https://wiki.openstack.org/**
>> wiki/Database_migration_**testing<https://wiki.openstack.org/wiki/Database_migration_testing> Dan Prince is the expert on this.
>>
>> I think the right process is:
>>
>> 1. Wait until the very beginning of Icehouse cycle.  (But not after we
>> have new migrations for Icehouse.)
>>
>> 2. Compact all migrations into 2xx_havana.py (for SQLAlchemy-migrate)
>>
>> 3. Test that it's perfect via above test plan plus whatever enhancements
>> we think of.
>>
>> 4. Manually convert 2xx_havana.py (for SQLAlchemy-migrate) into Alembic,
>> and verify that it's still perfect.
>>
>> 5. Deprecate the SQLAlchemy-migrate version and announce that new
>> migrations should be in Alembic.
>>
>> #4 is hard work but not impossible.  I have some old code that does 90%
>> of the work, so we only have to do the other 90%.
>>
>> --
>> David Ripton   Red Hat   dripton at redhat.com
>>
>>
>> ______________________________**_________________
>> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130717/864b3a4f/attachment.html>