alarm creation with sqlalchemy fails with intermittent IntegrityError
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceilometer |
Fix Released
|
High
|
Eoghan Glynn | ||
Havana |
Fix Released
|
High
|
Eoghan Glynn |
Bug Description
Alarm creation fails intermittently when the sqlalchemy driver is used:
(IntegrityError) (1452, 'Cannot add or update a child row: a foreign key constraint fails (`ceilometer`
This appears to be an artifact of how the alarm creation logic was added to the sqlalchemy driver in such a way as to rely on sqlalchemy session merge to create the corresponding entries in the project & user tables[1].
Then subsequently a *later* migration[2] was added to assert foreign key constraints for those project & user IDs.
I don't think session merge is a reliable way to ensure creation of the corresponding rows in the related tables in order to satisfy the foreign key constraints. Instead we should create the project & user IDs explicitly.
[1] https:/
[2] https:/
Changed in ceilometer: | |
assignee: | nobody → Eoghan Glynn (eglynn) |
status: | New → In Progress |
importance: | Undecided → High |
Changed in ceilometer: | |
milestone: | none → icehouse-1 |
tags: | added: havana-backport-potential |
summary: |
- alarm creation with sqlalchemy fails with IntegrityError due to - ForeignKey constraint on project ID + alarm creation with sqlalchemy fails with intermittent IntegrityError |
Changed in ceilometer: | |
status: | Fix Committed → Fix Released |
tags: | removed: havana-backport-potential |
Changed in ceilometer: | |
milestone: | icehouse-1 → 2014.1 |
Reviewed: https:/ /review. openstack. org/58587 github. com/openstack/ ceilometer/ commit/ b2b500c83cf5a81 269c84a16f9a30a b7fa4c8ee6
Committed: http://
Submitter: Jenkins
Branch: master
commit b2b500c83cf5a81 269c84a16f9a30a b7fa4c8ee6
Author: Eoghan Glynn <email address hidden>
Date: Tue Nov 26 16:35:36 2013 +0000
Avoid intermittent integrity error on alarm creation
Fixes bug 1255107
Previously, alarm creation failed intermittently with the
sqlalchemy driver, due to the reliance on session merge to create
the project & user IDs if not already encountered. This approach
conflicted with the strict foreign key constraints that were
added to the alarms table as an after-thought.
Now, we avoid the potential problem by explicitly creating the
project and user IDs if necessary.
Unfortunately, this cannot be tested via the scenario tests,
as there we use sqlite (the problematic migration does not
apply the foreign key constraints for that engine).
Change-Id: Ieaed676a0a6872 5242fadbf658646 b874d6851ce