alarm_history_project_fkey Constraint fails on el6 MySQL

[Dan Prince]

Using Ceilometer master I'm now getting the following exception when migration 015_add_alarm_history_table runs:

2013-09-12 18:52:26.251 12849 CRITICAL ceilometer [-] (OperationalError) (1005, "Can't create table 'ceilometer.#sql-3176_64' (errno: 121)") 'ALTER TABLE alarm_history ADD CONSTRAINT alarm_history_project_fkey FOREIGN KEY(project_id) REFERENCES project (id)' ()

[Eoghan Glynn (eglynn)]

This issue occurs because the add_alarm_history_table migration eagerly included mysql_engine='InnoDB' in the new table definition:
  https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/sqlalchemy/migrate_repo/versions/015_add_alarm_history_table.py#L42

with the expectation that https://review.openstack.org/45306 would have landed first.

With InnoDB explicitly selected for all tables or none, the 'ALTER TABLE' issue above does not occur.

[Eoghan Glynn (eglynn)]

Dan - now that https://review.openstack.org/45306 has landed, are you still seeing this issue?

[Eoghan Glynn (eglynn)]

Dan - on RHEL 6.4 with mysql 5.1.69, I'm seeing the ceilometer migrations run to completion.

If you're still seeing issues, can you attach the logs/stacktraces etc.?

BTW I did initially see an issue with an alembic migration failing due to:

  https://bugs.launchpad.net/ceilometer/+bug/1221467

i.e.:

  File "/opt/stack/ceilometer/ceilometer/storage/sqlalchemy/alembic/versions/b6ae66d05e3_remove_extra_indexes.py", line 68, in index_cleanup
      op.drop_constraint(uniq_name, table_name, type_='unique')
  TypeError: drop_constraint() got an unexpected keyword argument 'type_'

which may be resolved by updating the alembic version from 4.2 to 6.0.

[Dan Prince (dan-prince)]

Eoghan,

Ah yes. So we'll likely need to bump EPEL's alembic version >= 0.6 in order to avoid this I guess. It is in global-requirements.txt so I suppose it is fair game.

I'm not aware of any other Alembic issues with 4.2 ATM (which we use elsewhere) so this could be the first hard dependency on 6.0.

Dan

[Dan Prince (dan-prince)]

As far as I can tell Ceilometer is the only project requiring 0.6 at this point.

It looks like we only recently bumped it to 0.6 (which is only 2 months old) to fix bug #1221467. I'm wondering if perhaps we could avoid both of these issues by restructuring the migrations a bit. Perhaps dependency creep could be avoided here?

[Eoghan Glynn (eglynn)]

Dan - yes, it looks like this version bump was possibly not even required.

Two of the ceilometer alembic-based migrations use the new type_ kwarg in calls to op.drop_constraint(), even though the old 'type' form was retained for backward compatability:

  https://alembic.readthedocs.org/en/latest/ops.html
  "Changed in version 0.5.0: The type parameter is now named type_. The old name type will remain for backwards compatibility."

I'll look it reverting these migrations to use the old kwarg form to avoid imposing the newer version of alembic on all distros.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/48069

[Eoghan Glynn (eglynn)]

Corresponding change to the global requirements has landed:

  https://review.openstack.org/48227

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/48069
Committed: http://github.com/openstack/ceilometer/commit/0cd1c8baa626810339a87ce486f6470a4b1bcb99
Submitter: Jenkins
Branch: master

commit 0cd1c8baa626810339a87ce486f6470a4b1bcb99
Author: Eoghan Glynn <email address hidden>
Date: Tue Sep 24 14:35:32 2013 +0000

    Avoid imposing alembic 6.0 requirement on all distros

    Related-to: LP 1224666

    Two of the alembic-based migrations use the new 'type_' kwarg in calls
    to op.drop_constraint(), even though the old 'type' form was retained
    for backward compatability:

      https://alembic.readthedocs.org/en/latest/ops.html

      "Changed in version 0.5.0: The type parameter is now named type_.
      The old name type will remain for backwards compatibility."

    To avoid needlessly imposing the alembic 6.0 on distros for which this
    version is not yet packaged, we revert these migrations to use the older
    form.

    The corresponding change to the global requirements is proposed here:

      https://review.openstack.org/48227

    Change-Id: I3796ffa3de0e0f558f368d7ebf8e55c87657753d

[Dan Prince (dan-prince)]

This looks good to go now Eoghan. I think we can close it out....

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/havana
Review: https://review.openstack.org/84392