live_migration() takes exactly 7 arguments (6 given) if upgrade_levels compute=kilo

[Roman Sokolkov]

I have Liberty controller (nova-api, etc.) with

[upgrade_levels]
compute=kilo

and Liberty compute node, when i try live-migration
i see "live_migration() takes exactly 7 arguments (6 given)"
in nova-compute.log.

I can not completely remove compatibility with kilo,
because i have kilo computes in my env.

I also tried to add "upgrade_levels" to compute node,
but with no luck.

Environment
==========
Libvirt+KVM, Ceph for VMs
Liberty - Mirantis OpenStack 8.0 (2015.2)

Steps to reproduce
===============
1) Install Liberty control plane (api, conductor, schduler, etc.)
2) Install Liberty computes
3) Add to nova.conf on controller
  [upgrade_levels]
  compute=kilo
3) Try "nova live-migration VM"

Expected result
=============
Migration will succeed

Actual result
==========
Traceback on compute node
http://paste.openstack.org/show/521871/

[Timofey Durakov (tdurakov)]

it looks like a duplicate for https://bugs.launchpad.net/nova/+bug/1576048 but, could you please provide more logs, to confirm

[John Garbutt (johngarbutt)]

So I think what is happening here, is there are no nova-compute nodes in the DB, so the min_service_version = 0.

This is then cached in the nova-conductor until restart. The cache could be triggered by some query in the conductor that happens before any nova-compute starts up.

Later, nova-compute starts, and if the conductor is restarted we get the correct min_version.

I think the code needs to worry about the special case of having no services, and getting the min_version of that.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Change abandoned by John Garbutt (<email address hidden>) on branch: master
Review: https://review.openstack.org/337327
Reason: was just an idea

[Sean Dague (sdague)]

At this point, liberty is nearing EOL. So it's not really clear this is going to be a thing we address.

[Launchpad Janitor (janitor)]

[Expired for OpenStack Compute (nova) because there has been no activity for 60 days.]

[Oisin (oisin-omalley)]

I'm in the process of a Kilo to Liberty migration and am encountering this exact same issue when we attempt to live migrate instances from a Liberty to a Kilo Compute node. The Compute API is pinned to 4.0.

I've attempted Johns suggestion and restarted all nova-conductor services but it has had no affect.

Are there any suggestions and/or workarounds for this issue?

[Sean Dague (sdague)]

Both Kilo and Liberty are EOL

[Karim Boumedhel (karmab)]

@Oisin, did you eventually sort it out, same issue here

[Oisin (oisin-omalley)]

I found a work around for it, the additional parameter from the live_migration() function was added in the 4.2 rpcapi version. I found instances would live migrate from a Liberty either an liberty or Kilo compute node when the compute level was set to 4.2.

To live migrate from Kilo to Liberty on all Nova nodes set;
[upgrade_levels]
compute=4.0

To live migrate from Liberty to Liberty or liberty to Kilo nodes, set the compute level on Liberty Nova nodes to;
[upgrade_levels]
compute=4.2

During our rolling migration from Kilo to Liberty, compute level was set to 4.0 which enabled us to live migrate everything off Kilo compute nodes to Liberty nodes. The plan was if we encountered an issue with a Liberty node we could set the compute level to 4.2 and back out by live migrating the instance back to a Kilo or another Liberty node.