OpenStack Quantum integration feature page for 3.3

[Dan Kenigsberg]

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?

> 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