On Fri, Jul 1, 2016 at 8:34 AM, Murray, Paul (HP Cloud) <[email protected]> wrote: >> -----Original Message----- >> From: Carl Baldwin [mailto:[email protected]] >> Sent: 29 June 2016 22:20 >> To: OpenStack Development Mailing List (not for usage questions) >> <[email protected]> >> 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 >> <[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
