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 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
It is not quite the same as the example you gave about "green" network.
Of course. My "green" example was only showing that we can never really
tell that a future VM would see its required network.
A quote from "Network provisioning":
The network can be exported from oVirt into the network provider,
but
from that moment on it will be as if the network was discovered
from
the provider - i.e. if it goes out of sync, that's OK from oVirt's
perspective.
Could you explain what does "exporting a network from oVirt" means?
Do you
plan an API for that?
Yes, we plan to be able to create a network on the provider via oVirt,
instead of having the user do it via the Quantum API.
Could you define this "export" term on the feature page, or state which
Quantum API is going to be used for it?
Could you elaborate on why this feature depends on
http://www.ovirt.org/Features/Device_Custom_Properties ?
We need this to specify custom properties per vNIC also for hot
plug/wire. Otherwise we won't be able to support these features for
externally provided networks.
Which custom properties would you need? Are they going to depend on the
specific quatum vif type?
This feature heavily depends on http://www.ovirt.org/Network_Provider
Yes, it is an elaboration of the feture, not something independent.
To me, this separtion incur confusion. The fact that it happens for many
other features (http://www.ovirt.org/Features/Design/) only makes it
worse ;-)
.
Is there a real difference between the two? If not, I'd rename
Network_Provider to Features/Network_Provider and have
Quantum_Integration redirect to there.
Regards,
Dan.
_______________________________________________
Arch mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/arch
