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