Open Stack

Hi, I was looking at bug 1000609, which reflects the race condition
partially worked around in bug 998137. I've put a patch up to tighten
the code still further, but the underlying schema will still permit
bad data, so its possible we will regress, or some user will shoot
themselves in the foot.

To prevent those possibilities I'd normally make the columns NOT NULL,
so that the code expectations and the DB schema are in sync; to do
that requires a migration that a) checks for existing bad data (any
row with either column NULL) and deletes it, and b) will cause a table
scan (or two) if the columns are not indexed - and they don't appear
to be from code inspection (but this is my first time in the codebase,
I could well be wrong).

So - do we have a backfiller around, to do this with minimal
(subsecond) downtime in stages, or do we just bite the bullet and
accept that the migration will take as long as it takes? Its a very
narrow table, and I'd expect even pretty large sites to be looking at
no more than 10-20 seconds to perform the migration.

-Rob