Open Stack

Adam Young wrote:
> On 07/16/2012 11:59 PM, Jim Fehlig wrote:
>> I'm working on a patch that adds a column to the compute_nodes table in
>> the nova db, but it seems my db migration script fails when calling 'db
>> sync' in stack.sh.  I tried running the command manually, same failure:
>>
>> stack at virt71:~> /opt/stack/nova/bin/nova-manage --debug -v db
>> sync2012-07-16 21:42:52 DEBUG nova.utils [-] backend <module
>> 'nova.db.sqlalchemy.migration' from
>> '/opt/stack/nova/nova/db/sqlalchemy/migration.pyc'> from (pid=19230)
>> __get_backend /opt/stack/nova/nova/utils.py:484
>> /usr/lib64/python2.6/site-packages/sqlalchemy/pool.py:681:
>> SADeprecationWarning: The 'listeners' argument to Pool (and
>> create_engine()) is deprecated.  Use event.listen().
>>    Pool.__init__(self, creator, **kw)
>> /usr/lib64/python2.6/site-packages/sqlalchemy/pool.py:159:
>> SADeprecationWarning: Pool.add_listener is deprecated.  Use
>> event.listen()
>>    self.add_listener(l)
>> Command failed, please check log for more info
>>
>> I can't find anything useful in any log (/var/log/*, /opt/stack/log/*).
>> I ran the above in strace and saw my migration script was opened and
>> then shortly thereafter writing of "Command failed, please check log for
>> more info" and exit(1) :).
>>
>> The patch also adds a 'hypervisor_type' column to the instances table,
>> and that migration script succeeds!
>>
>> Any hints for debugging a db migration script?
>>
>> Thanks,
>> Jim
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
> I just went through this with a Keystone change.  What I would suggest
> is:
>
> 1.  Get a blank Database.
> 2.  Run the DB migration without  your scripts.
> 3. Get the SQL you want to run to work correctly from that step.
> 4. Add in a Database appropriate SQL script that has exactly your SQL
> from above.
> 5. Run the whole migration.
>
> Yes, it is a labor intensive and painful as it sounds.  You want to
> make sure that you have exactly the preconditions that your script
> expects.  What I had to do was actually go back and modify earlier DB
> init code due to the SQL alchemy column definition changing.
>
> Note this change:
> https://review.openstack.org/#/c/7754/9/keystone/common/sql/migrate_repo/versions/001_add_initial_tables.py
>
> I now have to explicitly create the token table to make sure it is the
> state it would be today.  Since my code had modified the token table,
> had I not done this,  by the end of "stage 1" SQL processing, the
> database would have had this table in "stage 2" state.
>
> Then I Went and added a SQL script for modifying the table.  Since I
> was altering a a table without dumping the data in it, it was a
> non-trivial change that SQL Alchemy couldn't handl (AFAICT). Instead,
> I added a SQL script:
> https://review.openstack.org/#/c/7754/9/keystone/common/sql/migrate_repo/versions/002_mysql_upgrade.sql
>
>
> Make sure you have a comparable Downgrade script, too.
>
> https://review.openstack.org/#/c/7754/9/keystone/common/sql/migrate_repo/versions/002_mysql_downgrade.sql

Thanks for the details Adam!  This is really helpful.

Regards,
Jim

>
>
>
> For Keystone, we run the upgrade using a stand alone executable
> keystone/bin/keystone-manage.  In nove, it looks like there is
> bin/nova-manage to do the same thing.  I am running using Eclipse and
> PyDev as my development environment, and using the integrated debugger
> to step through the code.  Makes it a lot less painful to debug.
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>