----- Original Message -----
> 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".
I think that quantum is just a mean to an end and assuming it works properly it should be "an implementation detail" completely transparent to the user so that all networks should be managed by quantum only. If this is the case we should have a procedure to migrate all networking to quantum during ovirt upgrade and thereafter use quantum solely.
To stress the point, it is an unnecessary added complexity for the user to be aware of quantum.

> > - 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.
On the same token I think we should aim for quantum to eventually own all network configuration regardless of the purpose and usage of the logical network (e.g. VM or non-VM).

> > * 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.
agree. Assuming we have the "Rosetta Plugin" it will greatly simplify accomplishing the heterogeneous cluster approach.

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