[Openstack] Grizzly -> Havana nova upgrade failure: Cannot drop index 'instance_uuid'

Jonathan Proulx jon at jonproulx.com
Mon Dec 30 19:56:42 UTC 2013


Unfortunately this doesn't seem to be doing it for me.

Working from Ubuntu 12.04 originally installed with Essex and
incrementally upgraded using cloud archive. The Grizzly -> Havana
transition choked, then I discovered your patch and like Blair copied
it in place.  After a bit of thrashing found this thread and
discovered the patch only works form a clean base so reverted my DB to
last night's dump (schema at
https://gist.github.com/jon-proulx/abb6af1ab7f3133671d2)

But migration is still choking with:

CRITICAL nova [-] (OperationalError) (1032, "Can't find record in
'task_log'") 'ALTER TABLE task_log DROP INDEX
uniq_task_name_x_host_x_period_beginning_x_period_ending' ()

mysql> show create table task_log;
CREATE TABLE `task_log` (
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  `deleted_at` datetime DEFAULT NULL,
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `task_name` varchar(255) NOT NULL,
  `state` varchar(255) NOT NULL,
  `host` varchar(255) NOT NULL,
  `period_beginning` datetime NOT NULL,
  `period_ending` datetime NOT NULL,
  `message` varchar(255) NOT NULL,
  `task_items` int(11) DEFAULT NULL,
  `errors` int(11) DEFAULT NULL,
  `deleted` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_task_name_x_host_x_period_beginning_x_period_ending`
(`task_name`,`host`,`period_beginning`,`period_ending`),
  KEY `ix_task_log_host` (`host`),
  KEY `ix_task_log_period_ending` (`period_ending`),
  KEY `ix_task_log_period_beginning` (`period_beginning`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8


-Jon

On Wed, Oct 30, 2013 at 8:29 PM, Joshua Hesketh
<joshua.hesketh at rackspace.com> wrote:
> Hi Blair,
>
> No trouble, glad I could help. I'll be working backporting this as is
> appropriate.
>
> Cheers,
> Josh
>
> Rackspace Australia
>
>
> On 10/30/13 5:06 PM, Blair Zajac wrote:
>>
>> Hi Joshua,
>>
>> Thanks for the quick fix, I appreciate it.
>>
>> I took your fixed 185_rename_unique_constraints.py, copied it into
>> /usr/share/pyshared/nova/db/sqlalchemy/migrate_repo/versions/185_rename_unique_constraints.py,
>> restored MySQL back to 1 week ago and reran all the migrations and
>> everything worked fine.
>>
>> I've launched my instances, so I'm a happy openstacker ;)
>>
>> Thanks!
>> Blair
>>
>> On 10/29/2013 09:05 PM, Joshua Hesketh wrote:
>>>
>>> Hi Blair,
>>>
>>> I have proposed a new fix which I believe should work for you. However
>>> I've been unable to determine where exactly the duplicate keys were
>>> introduced. Looking up what versions were available in Ubuntu from 12.10
>>> you have been running since Folsom. This means you did not have the
>>> 133_folsom.py migration and should have skipped it when upgrading to
>>> Grizzly. I can't see anywhere else that would have changed the fkeys.
>>>
>>> So what I have proposed is to do a check for which keys exist in both of
>>> the problematic tables (as virtual_interfaces is also affected) and
>>> remove them bringing the databases inline with 133_folsom users.
>>>
>>> I'll propose this for backporting into Havana after it is merged.
>>>
>>> Cheers,
>>> Josh
>>>
>>> Rackspace Australia
>>>
>>> On 10/30/13 11:42 AM, Blair Zajac wrote:
>>>>
>>>> On 10/29/2013 05:16 PM, Joshua Hesketh wrote:
>>>>>
>>>>> Hi Blair,
>>>>>
>>>>> Thanks for the clarifications, that helps.
>>>>>
>>>>> At the moment I'm trying to determine how you ended up with both fkeys
>>>>> so I can ensure the problem is properly fixed. What version did you
>>>>> first start deploying openstack from? Essex? and have you been just
>>>>> upgrading with releases or RC's or upstream etc.
>>>>
>>>>
>>>> I don't remember exactly, but here's a best shot.  I keep my systems
>>>> up to date on Ubuntu, so:
>>>>
>>>> 1) Somewhere during 12.10 I installed OpenStack, I don't have notes on
>>>> which one.
>>>>
>>>> 2) By the time I upgraded to 13.04 I had 2012.2.1-0ubuntu1.3 installed
>>>> as I have the 'dpkg -l' output saved just before the upgrade. I was
>>>> using the packages from ubuntu-cloud.archive.canonical.com for 12.04
>>>> even though I was on 12.10.  Upgrading to 13.04 upgraded OpenStack to
>>>> 1:2013.1-0ubuntu1.
>>>>
>>>> 3) When I upgraded to 13.10 I switched from
>>>> ubuntu-cloud.archive.canonical.com back to 13.10's native OpenStack
>>>> packages.  This brought me to 1:2013.2~rc4-0ubuntu1 and which have
>>>> been since updated to 1:2013.2-0ubuntu1.
>>>>
>>>> Hope that helps.
>>>>
>>>> Blair
>>>>
>>>
>>
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack




More information about the Openstack mailing list