[Keystone][Nova] Why migrate_version not InnoDB?

[Brant Knudson]

'Stackers -

I've got a review up in Keystone that converts tables from MyISAM to InnoDB [0], which I patterned after a change in Nova. One of the comments in the review is suggesting that the migrate_version table should also be changed. The reason I didn't include migrate_version is because that's the way Nova did it, but other than that I don't know why migrate_version should not be converted. The Nova code is pretty explicit that migrate_version isn't changed [1]. Maybe somebody who knows MySQL or SQLAlchemy-migrate better than I do can come up with a reason why migrate_version shouldn't be changed from MyISAM to InnoDB.

[0] https://review.openstack.org/#/c/33102/ - Use InnoDB for MySQL
[1] https://github.com/openstack/nova/blob/master/nova/tests/db/test_migrations.py#L331

- Brant

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[David Ripton]

On 07/01/2013 12:49 PM, Brant Knudson wrote:

> 'Stackers -
>
> I've got a review up in Keystone that converts tables from MyISAM to
> InnoDB [0], which I patterned after a change in Nova. One of the
> comments in the review is suggesting that the migrate_version table
> should also be changed. The reason I didn't include migrate_version is
> because that's the way Nova did it, but other than that I don't know why
> migrate_version should not be converted. The Nova code is pretty
> explicit that migrate_version isn't changed [1]. Maybe somebody who
> knows MySQL or SQLAlchemy-migrate better than I do can come up with a
> reason why migrate_version shouldn't be changed from MyISAM to InnoDB.
>
> [0] https://review.openstack.org/#/c/33102/ - Use InnoDB for MySQL
> [1]
> https://github.com/openstack/nova/blob/master/nova/tests/db/test_migrations.py#L331

sqlalchemy-migrate relies on the migrate_versions table, so modifying it
from within a sqlalchemy-migrate script is scary.  And it's a tiny table
that's only used during DB migrations, so I doubt you'd see any actual
benefit.

--
David Ripton   Red Hat   [hidden email]

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Dolph Mathews]

On Mon, Jul 1, 2013 at 3:24 PM, David Ripton <[hidden email]> wrote:

On 07/01/2013 12:49 PM, Brant Knudson wrote:

'Stackers -

I've got a review up in Keystone that converts tables from MyISAM to
InnoDB [0], which I patterned after a change in Nova. One of the
comments in the review is suggesting that the migrate_version table
should also be changed. The reason I didn't include migrate_version is
because that's the way Nova did it, but other than that I don't know why
migrate_version should not be converted. The Nova code is pretty
explicit that migrate_version isn't changed [1]. Maybe somebody who
knows MySQL or SQLAlchemy-migrate better than I do can come up with a
reason why migrate_version shouldn't be changed from MyISAM to InnoDB.

[0] https://review.openstack.org/#/c/33102/ - Use InnoDB for MySQL
[1]
https://github.com/openstack/nova/blob/master/nova/tests/db/test_migrations.py#L331

sqlalchemy-migrate relies on the migrate_versions table, so modifying it from within a sqlalchemy-migrate script is scary.  And it's a tiny table that's only used during DB migrations, so I doubt you'd see any actual benefit.

+1; we don't explicitly create the migrate_versions table in migrations, so we shouldn't be managing it either. If there's an issue in that table, I'd say it's most likely on sqlalchemy-migrate or the deployer to fix, not keystone's migrations.

 

--
David Ripton   Red Hat   [hidden email]

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

-Dolph

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Adam Young]

On 07/05/2013 10:57 AM, Dolph Mathews wrote:

On Mon, Jul 1, 2013 at 3:24 PM, David Ripton <[hidden email]> wrote:

On 07/01/2013 12:49 PM, Brant Knudson wrote:

'Stackers -

I've got a review up in Keystone that converts tables from MyISAM to
InnoDB [0], which I patterned after a change in Nova. One of the
comments in the review is suggesting that the migrate_version table
should also be changed. The reason I didn't include migrate_version is
because that's the way Nova did it, but other than that I don't know why
migrate_version should not be converted. The Nova code is pretty
explicit that migrate_version isn't changed [1]. Maybe somebody who
knows MySQL or SQLAlchemy-migrate better than I do can come up with a
reason why migrate_version shouldn't be changed from MyISAM to InnoDB.

[0] https://review.openstack.org/#/c/33102/ - Use InnoDB for MySQL
[1]
https://github.com/openstack/nova/blob/master/nova/tests/db/test_migrations.py#L331

sqlalchemy-migrate relies on the migrate_versions table, so modifying it from within a sqlalchemy-migrate script is scary.  And it's a tiny table that's only used during DB migrations, so I doubt you'd see any actual benefit.

+1; we don't explicitly create the migrate_versions table in migrations, so we shouldn't be managing it either. If there's an issue in that table, I'd say it's most likely on sqlalchemy-migrate or the deployer to fix, not keystone's migrations.

Ah, but we do create that table:  That is what is meant by "Database already managed."  It is part of our application, and we are responsible for it.  It is just done as a side effect of us using the migration code at all.

 

--
David Ripton   Red Hat   [hidden email]

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

-Dolph

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev