[Engine-devel] quantum-ovirt integration meeting summary

[Gary Kotton]

Hi,
Thanks for the time yesterday. Please see my inline comments.
Please feel free to contact me if you have any additional questions.
Thanks
Gary

On 06/06/2012 09:41 PM, Livnat Peer wrote:
> Hi All,
>
> This is a summary of the first quantum-oVirt integration meeting.
>
> In the meeting Garry Kotton started presenting his proposal for the
> integration, for more details on his proposal look in -
> http://www.ovirt.org/wiki/Quantum_and_oVirt
>
> We did not cover much of the wiki as some question arose:
>
> * What is the end goal of the integration? is it to replace the current
> network configuration implementation in oVirt by quantum or have them
> side by side.
I think that the first phase should enable them to work together. That 
is, the user can have host that run traditional VDSM networking and host 
that run a specific Quantum agent. In addition to this. I think that the 
user should also have the flexibility to choose which network interfaces 
run Quantum or traditional VDSM.
In short the answer is "side by side".
> - we need to remember non-VM networks (like storage and migration networks)
The crystallizes the point above, management and storage can continue to 
use the existing VDSM networking and the VM networks can start to use 
Quantum.
> * Will oVirt use multiple quantum instances, one per technology, or will
> oVirt use a single quantum instance that should support multiple
> plug-ins (not supported in Quantum ATM)
oVirt should use one Quantum instance. Today I will draw up a blueprint 
for Quantum to have a "Rosetta Plugin", that is a plugin that can 
support a number of different networking technologies.
> * We'll oVirt support a mix of different technologies in a DC, Cluster,
> host?
I think that the only limitation should be to run one Quantum agent per 
host.
> - Can we assume homogeneous clusters for the sake of simplicity (in a
> single cluster we'll support either open Vswitch or UCSM or ..)
I do not think that we should go for a simple solution, but we should 
strive for a proper solution. I see no reason to prevent or limit this. 
I feel that this would be a hard limitation for oVirt users. A example 
to show this limitation is the addition of a host to the existing 
cluster that has new networking capabilities that are supported by a 
different Quantum plugin.
oVirt must be aware of the capabilities of each host to indicate to the 
user that certain operations may not be possible, or may cause the 
virtual machine to behave differently (performance degradation for 
example), if they have decided to work in this manner - for example live 
live migration.
> - Logical Network is defined in the scope of a data center, that means
> we need to maintain layer 2 connectivity and within a cluster we need to
> guarantee VM live migration (does libvirt abstract it for us?)
Once again, oVirt should be aware of the host characteristics. This will 
not only be the hardware but also the software running on the host. This 
will enable oVirt to indicate to the user what is and what is not possible.
>
> other notes -
>
> * The UUIDs that are returned by Quantum will be managed by oVirt and
> for a single network implemented in two different technologies in
> quantum oVirt will be responsible to sync the different IDs.
This is not relevant as oVirt will work with only one Quantum server - 
that is, each logical network will have only one UUID.
> * The integration should be as seamless as possible to the user of oVirt
+1
> * support of existing VLAN in quantum should be introduces in quantum in
> a 3-4 weeks time-frame
This is scheduled for Folsom-2 
(https://launchpad.net/quantum/+milestone/folsom-2). I do not see any 
blockers at the moment to prevent the start of integration.
>
>
> Comments are welcomed, I'll schedule a follow up next week.
I will try and prepare some diagrams that will maybe help us with the 
next talk. I'll post these as soon as they are ready.
> Thanks, Livnat
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel