Open Stack

On Fri, Jul 1, 2016 at 8:34 AM, Murray, Paul (HP Cloud) <pmurray at hpe.com> wrote:
>> -----Original Message-----
>> From: Carl Baldwin [mailto:carl at ecbaldwin.net]
>> Sent: 29 June 2016 22:20
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Nova][Neutron][Live-Migration] Cross l2 agent
>> migration and solving Nova-Neutron live migration bugs
>>
>> On Tue, Jun 28, 2016 at 9:42 AM, Andreas Scheuring
>> <scheuran at linux.vnet.ibm.com> wrote:
>> > I'm currently working on solving Nova-Neutron issues during Live
>> > Migration. This mail is intended to raise awareness cross project and
>> > get things kicked off.
>>
>> Thanks for sending this.
>>
>> > The issues
>> > ==========
>> >
>> > #1 When portbinding fails, instance is migrated but stuck in error
>> > state
>> > #2 Macvtap agent live Migration when source and target use different
>> > physical_interface_mapping [3]. Either the migration fails (good case)
>> > or it would place the instance on a wrong network (worst case)
>> > #3 (more a feature):  Migration cross l2 agent not possible (e.g.
>> > migrate from lb host to ovs host, or from ovs-hybrid to new
>> > ovsfirewall
>> > host)
>>
>> Since all of these issues are experienced when using live migration, a Nova
>> feature, I was interested in finding out how Nova prioritizes getting a fix and
>> then trying to align Neutron's priority to that priority.  It would seem artificial
>> to me to drive priority from Neutron.  That's why I mentioned it.  Since Nova
>> is hitting a freeze for non-priority work tomorrow, I don't think anything can
>> be done for Newton.  However, there is a lot of time to tee up this
>> conversation for Ocata if we get on it.
>>
>
> I read the comments from the neutron meeting here: http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-06-30-22.00.log.html#l-320 and thought a little commentary on our priorities over the last couple of cycles might avoid any misconception.
>
> Live migration was a priority in Mitaka because it simply was not up to scratch for production use. The main objective was to make it work and make it manageable. That translated to:
>
> 1. Expand CI coverage
> 2. Manage migrations: monitor progress, cancel migrations, force spinning migrations to complete
> 3. Extend use cases: allow mix of volumes, shared storage and local disks to be migrated
> 4. Some other things: simplify config and APIs, scheduling support, separate migration traffic from management network
>
> These were mostly covered including some supporting work on qemu and libvirt as well.
>
> We next wanted to do some security work (refactoring image backend and removing ssh-based copy - aka storage pools) but that could not be done in Mitaka and was deferred. The priority for Newton was specifically this security work and continuing efforts on CI which is now making progress (ref: the sterling work by Daniel Berrange in the last couple of days: http://lists.openstack.org/pipermail/openstack-dev/2016-June/098540.html )

Paul, thanks for your reply, it is helpful.  I look forward to
discussing it with the Nova team at the mid-cycle.

Carl