Open Stack

It seems I'm reading the error wrong, the problem is that there is
already an index using the same name & MySQL won't also use that name
for a constraint.  If I remove the index the constraint can be
created, but then I'm loosing the index and diverging from the norm
which seems likely to ensure trouble in the future.  So far I've hit
uniq_task_log0task_name0host0period_beginning0period_ending on
task_log, uniq_instance_types0name0deleted and uniq_flavorid_x_deleted
on instance_types.

The other recurring issue seems to be attempting  to drop indexes that
don't exist (so far
uniq_task_name_x_host_x_period_beginning_x_period_ending on task_log,
uniq_name_x_deleted  on instance_types, and uniq_flavorid_x_deleted
on instance_types) if I create these indexes so they can be dropped
the migration continues (to the next error).

and I keep uncovering similar errors every step I take, so I'm a bit
worried at this point

-Jon


On Mon, Dec 30, 2013 at 11:09 AM, Jonathan Proulx <jon at jonproulx.com> wrote:
> Hi All,
>
>  nova-manage  db sync is failing fro me with:
>
> 2013-12-30 10:53:22.795 3323 CRITICAL nova [-] (OperationalError)
> (1061, "Duplicate key name
> 'uniq_task_log0task_
> name0host0period_beginning0period_ending'") 'ALTER
> TABLE task_log ADD CONSTRAINT
> uniq_task_log0task_name0host0period_beginning0period_ending UNIQUE
> (task_name, host, period_beginning, period_ending)' ()
>
> the table being modified is empty, so I'm a bit puzzled if this is
> saying the UNIQUE constraint can't be satisfied, which is how I'm
> reading it.
>
> upgrading from Grizzly to Havana.  The system is running Ubuntu 12.04
> using cloud archive, was originally installed with essex and
> incrementally upgraded since (I mention this because I also hit
> https://bugs.launchpad.net/nova/+bug/1245502 which is patched but not
> in the cloud archive bits yet, that's the only local modification so
> far on Hanava)
>
> Help?
> -Jon