OpenStack Quantum integration feature page for 3.3

Tue Apr 9 07:16:04 UTC 2013

----- Original Message -----
> On 04/08/2013 07:13 PM, Dan Kenigsberg wrote:
> > On Fri, Mar 22, 2013 at 08:34:14AM +0200, Gary Kotton wrote:
> >> On 03/21/2013 11:06 PM, Dan Kenigsberg wrote:
> >>> On Thu, Mar 21, 2013 at 03:53:38PM +0200, Gary Kotton wrote:
> >>>> On 03/21/2013 03:12 PM, Dan Kenigsberg wrote:
> >>>>> On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote:
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> The feature page for integrating OpenStack Quantum into oVirt is
> >>>>>>>> available on the wiki:
> >>>>>>>> http://www.ovirt.org/Features/Quantum_Integration
> >>>>>>>>
> >>>>>>> A quote from "Network discovery":
> >>>>>>>> Currently, we assume that the networks provided by the provider are
> >>>>>>>> available on all hosts in the data center...
> >>>>>>> it is not completely clear who are "we" there. I suppose that you
> >>>>>>> mean
> >>>>>>> that Engine takes this assumption, and does not verify that a
> >>>>>>> specific
> >>>>>>> host is actually connectable by the network provider. That's not much
> >>>>>>> worse than what Engine does elsewhere: it does not verify that
> >>>>>>> network
> >>>>>>> "green" in one host can actually connect with network "green" on
> >>>>>>> another
> >>>>>>> host.
> >>>>>> "We" is oVirt as a whole.
> >>>>>>
> >>>>>> Currently we do know which network is available on which host since
> >>>>>> the user set it up.
> >>>>>> In the planned integration we wouldn't know, thus we will consider
> >>>>>> external network as "provided".
> >>>>> So *Engine* cannot tell if a host is controllable by the defined
> >>>>> quantum
> >>>>> server, and therefore it has to assume that everything is all right,
> >>>>> putting this burden on the end user.
> >>>>>
> >>>>> Garry, does Quantum provide any means to tell - ahead of time - if
> >>>>> provisioning a virtual network to a specific work is expected to
> >>>>> succeed? Or, let's say, that the host is utterly misconfigured and is
> >>>>> unknown to Quantum? Can it at least be done for plugins with host
> >>>>> agents?
> >>>> I am not really sure that I understand your question. Can you please
> >>>> clarify what you mean by "if provisioning a virtual network ... is
> >>>> expected to succeed".
> >>>>
> >>>> Lets take two open source examples:
> >>>> openvswitch - a integration bridge is provisioned ahed of time, that
> >>>> is, each host will need to provision an integration bridge on the
> >>>> OVS. When the agent detects that new port is created on the bridge
> >>>> then it will configure the relevant VLAN. The Quantum service will
> >>>> be notified that the port is "UP"
> >>>> linuxbridge - the nova host that is deplying the VM will create the
> >>>> networkwork if it does not exist. If this fails the a VM will not be
> >>>> spawned. Once the network is up the agent will configure the VLAN.
> >>>> The quantum service will be notified that the port is "UP"
> >>>>
> >>>> The assumption is that the hosts will be configured correctly. If
> >>> I would like to have a clue - ahead of time - if that assumption is
> >>> valid. The two examples above require the host to notify the Quantum
> >>> service. But what if the host agent is notifying an utterly different
> >>> service? Is there some kind of liveliness check between the host and its
> >>> Quantum service?
> >> The communication between the host and the quantum service is done
> >> by a message broker. If the host is updating a different service
> >> then the port state will not be set as "UP"
> >> In grizzy a feature was added where one is able to get the state of
> >> the agents for example:
> >>
> >> openstack at dhcp-4-227:~/devstack$ quantum agent-list
> >> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> >> | id                                   | agent_type         | host
> >> | alive | admin_state_up |
> >> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> >> | 1ab54438-9338-4050-a818-7faf28d31eb2 | DHCP agent         |
> >> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> >> | 396f03eb-b3af-4ddf-b52f-6a0de65b0574 | L3 agent           |
> >> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> >> | 876c7474-9e2e-4533-a27e-1de8ac3544c6 | Open vSwitch agent |
> >> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> >> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> >>
> >> If you get an XXX instead of a :) then the agent is down. The above
> >> is used for scheduling networks and routers to the dhcp and l3
> >> agents respectively.
> >>
> >> Does this help?
> > Yes. It seems that this is done at the Quantum server. Is it exposed by
> > the Quantum API or an extension thereof?
> 
> This is exposed by a Quantum extension. It is not part of the official
> API and may not be supported by some plugins.
> You are nonetheless able to query which extensions are supported by the
> plugin.
> 
> >
> > This information is valuable for scheduling VMs, and I'd like to
> > understand how oVirt can tap into it.
> 
> If the above extension is supported and the agent on the host is down
> then the scheduler should exclude that host - if that host is selected
> then the VM will not have network connectivity.
> 
> >
> > Also, what happens with agent-less plugins? Can Quantum tell who are the
> > hosts that it controls?
> 
> This depends on the extensions supported by the plugin.
> 
> At the moment there is a patch in progress (Havana) which will have the
> extension for the port bindings store the host. Once again this may not
> be supported by some plugins.

Do you know if it will be supported for Linux Bridge & OVS plugins?

> 
> >
> > Regards,
> > Dan.
> 
> 