Re: [Engine-devel] quantum-ovirt integration meeting summary

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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel