OpenStack Quantum integration feature page for 3.3

[Gary Kotton]

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?

>
>> not the the Quantum port will be "DOWN" (this can be detected via
>> interfacing with the quantum service)
>>
>> In Grizzly things are complicated a little more as the hosts are
>> also responsible for the configuartion of the security groups for
>> the port in question.
>>
>> Hope that this helps unless I have completely misunderstood your question.
>>
>> Thanks
>> Gary