----- 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@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? > > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
