OpenStack Quantum integration feature page for 3.3

Tue Apr 9 11:45:05 UTC 2013

On 04/09/2013 11:01 AM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 04/09/2013 10:16 AM, Mike Kolesnik wrote:
>>> ----- 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?
>> Yes, this is currently supported by these plugins.
>>
> Is there an API reference that you can please provide that documents this extension?

The available extensions can be retrieved via - 
http://docs.openstack.org/api/openstack-network/2.0/content/retrieve_extensions.html

You can also look at 
http://docs.openstack.org/trunk/openstack-network/admin/content/demo_multiple_operation.html

The code is always the most up to date :)

https://github.com/openstack/quantum/blob/master/quantum/extensions/agentscheduler.py

>
>>