Open Stack

As Gary said, Quantum at the moment does not have explicit awareness of the
physical location of a VIF.
Also, some plugins, like the OVS plugin, and I believe the Linux Bridge as
well, are really agnostic. They merely contain a database of logical ports;
the agents, which are running on the hosts, whenever they 'detect' a new
VIF has been plugged, query the Quantum service to fetch information about
that port and configure it.

It is debatable whether do we need to surface the physical location of the
VIF from the Quantum API. It is a discussion that comes fairly often on
this mailing list, but so far we have not found any strong reason for
exposing this concept. However, it is understandable that some plugins
might be architected in a way such that this kind of knowledge is required.
>From the Quantum side, this could be achieved with an API extension
(extended attributes might be structured as admin-only); from the nova
side, the current module would not be sufficient; at a first glance it
seems that it should be possible to create a 'plugin-specific' module by
deriving from the 'base' one, but I need to think more about it to state
whether that's the correct approach or not.

As regards live migration I agree that it's a slightly different topic, and
might require to be approach differently. Is that something you are aiming
to address to in the Grizzly release cycle? If yes, I'd be happy to talk a
little bit about possible strategies.

Regards,
Salvatore

On 31 October 2012 07:39, Irena Berezovsky <irenab at mellanox.com> wrote:

> Just to be sure that we talk about the same thing, the idea is to extend
> the Quantum Core Admin API  with  additional attribute specifying port
> physical location, particularly 'create_port' and 'update_port' should be
> extended. Am I right?
> To support live migration it may be a little more complicated, since there
> is a period of time that VM is moving to destination host but still working
> on source host.
> So probably port should be extended to contain simultaneously physical
> location info both for source and destination hosts. Since source and
> destination host is just temporary state of the Physical Host for certain
> VM, there is probably some sort of state machine to manage 'Hosting node'
> info.
> From nova side there are several events that may trigger calls to Quantum
> API with  regards to this ( I am sure the list is not complete):
> 1. VM is spawned =>port is created  with hosting host info
> 2. before VM starts migration on destination node => update port with
> destination node location info
> 3. after VM completes migration on source node => update port that source
> node info should be removed
> 4. VM fails to migrate to destination node => update port that destination
> node info should be removed.
> 5. after VM completes migration on destination node => update port with
> destination node location as 'Hosting node'
> 6. VM is terminated/paused => port is deleted
>
>
> There is also some concern with regards to Quantum agent, i.e.
> LinuxBridgeQuantumAgent that updates the port status at Server side once
> connects/disconnects VIF on the Host.
> In case of live migrations, it may disconnect the VIF on the source node
> after connecting VIF on the  destination node. I am not sure but I think
> this may lead to setting port state to 'Down'; at least till next polling
> interval at destination node.
>
> Irena
>
>
>
> -----Original Message-----
> From: Dan Wendlandt [mailto:dan at nicira.com]
> Sent: Tuesday, October 30, 2012 11:47 PM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] Quantum awareness to VM live migration event
>
> On Tue, Oct 30, 2012 at 2:26 PM, Sasha Ratkovic <sasharatkovic at juniper.net>
> wrote:
> > Dan,
> >
> > This is an example of use of "endpoint" abstraction (with attribute
> "host" for example). Issuing a "PUT" on this attribute would indicate VM
> motion (request) and request for port reassignment (quantum response).
> >
> > Thanks,
> > Sasha
>
> I'm not sure we're talking about the same thing here.  In this case,
> 'host' is not a virtual server, but rather the physical host currently
> running the virtual server.  In Quantum terms, this might be more generally
> be called a 'switch', since Quantum can connect logical devices other than
> VMs.
>
> dan
>
>
> >
> > -----Original Message-----
> > From: Dan Wendlandt [mailto:dan at nicira.com]
> > Sent: Tuesday, October 30, 2012 10:08 AM
> > To: Salvatore Orlando
> > Cc: OpenStack Development Mailing List
> > (openstack-dev at lists.openstack.org)
> > Subject: Re: [openstack-dev] Quantum awareness to VM live migration
> > event
> >
> > On Tue, Oct 30, 2012 at 2:28 AM, Salvatore Orlando <sorlando at nicira.com>
> wrote:
> >> Hi Irena,
> >>
> >> I do apologise for not having been more clear.
> >> I was wondering if you are planning to extend the Quantum API,
> >> besides the module that interfaces nova to quantum, in order to
> >> accomodate migration events.
> >> At a first glance, I believe this process could be entirely managed
> >> using the existing Quantum API, but I have not explored the problem
> >> in detail, so I might be missing something.
> >>
> >> Salvatore
> >
> > At the summit, we talked about adding calls to the Quantum admin API for
> a service to tell Quantum what host a particular port is being placed on
> (or removed from).  This helps solve some of the vif-plugging issues gary
> was talking about, but could also be seen as a mechanism by which nova
> could indicate that a port have been removed from one host, and placed on
> another as a result of a VM migration.
> >
> > dan
> >
> >
> >>
> >>
> >> On 30 October 2012 09:20, Irena Berezovsky <irenab at mellanox.com> wrote:
> >>>
> >>> Moving the ongoing discussion to the openstack-dev mailing list
> >>>
> >>>
> >>>
> >>> Salvatore,
> >>>
> >>> Thank you for comments.
> >>>
> >>> I would like to add additional methods to quantum API corresponding
> >>> the VM migration methods defined at nova/network/api.
> >>>
> >>> I am not sure what do you mean by server side calls to quantum.
> >>>
> >>> Just to be sure how to proceed, shall we create the blueprint for
> >>> this task?
> >>>
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Irena
> >>>
> >>>
> >>>
> >>> On 30 October 2012 08:16, Salvatore Orlando <sorlando at nicira.com>
> wrote:
> >>>
> >>> Hi Irena,
> >>>
> >>>
> >>>
> >>> I am afraid you're correct. VM migration events were not addressed
> >>> in the nova-quantum api for Folsom.
> >>>
> >>> We definitely want to add those calls - and help would be extremely
> >>> appreciated.
> >>>
> >>>
> >>>
> >>> I think the nova-to-quantum API was mostly implemented by Yong -
> >>> with some contribution from Dan, me, and other Quantum devs.
> >>>
> >>>
> >>>
> >>> Are you planning to add also server-side calls to Quantum for
> >>> migration awareness?
> >>>
> >>>
> >>>
> >>> Salvatore
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 30 October 2012 08:13, Irena Berezovsky <irenab at mellanox.com>
> wrote:
> >>>
> >>> Hi guys,
> >>> I have troubles to follow the flow of events in case of VMlive
> migration.
> >>> Can I ask  you for clarifications?
> >>> What I see from the code is that there is no additions to  Quantum
> >>> API for migration awareness.
> >>> At
> >>> https://github.com/openstack/nova/blob/master/nova/network/quantumv2
> >>> /
> >>> api.py
> >>> there is just empty implementation.
> >>> Is there an intension to add Quantum API calls for live migration?
> >>> Is it only nova related actions? Is some help needed?
> >>>
> >>> I am looking for a way to be aware of live migration at quantum
> >>> plugin (due to the need to configure physical server that attached
> >>> to the host that hosts VM).
> >>> Thanks a lot,
> >>> Irena
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Gary Kotton [mailto:gkotton at redhat.com]
> >>> Sent: Sunday, October 28, 2012 10:34 AM
> >>> To: Irena Berezovsky
> >>>
> >>> Cc: Dan Wendlandt; Salvatore Orlando
> >>> Subject: Re: Quantum awareness to VM live migration event
> >>>
> >>> On 10/28/2012 10:27 AM, Irena Berezovsky wrote:
> >>> > Hi Dan,
> >>> > Thank you very much for your response.
> >>> > Salvatore, Gary may I ask few questions regarding this  change?
> >>> > 1. Is there some blueprint covering support for VM migration calls
> >>> > to quantum API (data passed by nova) and DB model changes (if any)?
> >>>
> >>> Not that I am aware of
> >>> > 2. Is there some description of VM migration  flow from nova
> >>> > perspective?
> >>>
> >>> Ditto
> >>> > 3. Is it part of Folsom release?
> >>>
> >>> Yes, this should be supported and working.
> >>> > 4. Does it handle case when VM Migration fails?
> >>>
> >>> I would hope so.
> >>> > 5. As far as I understand,  in migrate_instance_finish there is a
> >>> > 'dest ' attribute. I believe its destination Physical host UUID.
> >>> > In migrate_instance_start there is a 'host' attribute. Is it
> >>> > source Physical Host UUID?
> >>>
> >>> I am not familiar with this.
> >>> >
> >>> > Thank you in advance,
> >>> > Irena
> >>> >
> >>> >
> >>> > -----Original Message-----
> >>> > From: Dan Wendlandt [mailto:dan at nicira.com]
> >>> > Sent: Saturday, October 27, 2012 2:46 AM
> >>> > To: Irena Berezovsky
> >>> > Cc: Salvatore Orlando; Gary Kotton
> >>> > Subject: Re: Quantum awareness to VM live migration event
> >>> >
> >>> > Hi Irena,
> >>> >
> >>> > Sorry, just now starting to catch up on email post-summit.
> >>> >
> >>> > I'm CC'ing Salvatore and Gary, as they are also involved in this,
> >>> > I believe.
> >>> >
> >>> > Salvatore was involved with discussions with Vish and the Nova
> >>> > team around the addition of migration hooks to the network api
> >>> > within nova,
> >>> > see:
> >>> > https://github.com/openstack/nova/blob/master/nova/network/api.py#
> >>> > L
> >>> > 337
> >>> >
> >>> > Gary's talk on the summit also touches on this, and would likely
> >>> > add the admin calls to the Quantum API that indicate that a port
> >>> > is about to be provisioned on a particular physical host (this
> >>> > would probably be sent to quantum from nova when a VM is
> started/stopped, or migrated.
> >>> >
> >>> > Dan
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Mon, Oct 15, 2012 at 11:01 AM, Irena
> >>> > Berezovsky<irenab at mellanox.com>
> >>> > wrote:
> >>> >> Dan,
> >>> >> Continuing our talk today, please let me know if there is some
> >>> >> work about Quantum awareness to VM live migration event (before
> >>> >> and after on source and destination nodes).
> >>> >>
> >>> >> I would lie to be part of it,
> >>> >>
> >>> >> Thanks,
> >>> >> Irena
> >>> >
> >>> >
> >>> > --
> >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>> > Dan Wendlandt
> >>> > Nicira, Inc: www.nicira.com
> >>> > twitter: danwendlandt
> >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Dan Wendlandt
> > Nicira, Inc: www.nicira.com
> > twitter: danwendlandt
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121031/6dff610a/attachment-0001.html>