OpenStack Quantum integration feature page for 3.3

[Mike Kolesnik]

----- Original Message -----
> On 03/18/2013 09:20 AM, 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
> >
> > Please comment.
> >
> > Regards,
> > Mike
> >
> 
> A few questions/comments (inlining relevant parts of
> http://www.ovirt.org/Features/Detailed_Quantum_Integration)

Thanks for the comments and questions, I have answered in-line.

> 
> > Support for OVS plugin?
> 
> ovs vs. bridge - since we already have bridge support in oVirt, i think
> ovs support is a higher motivation for integrating with quantum.

Of course, we will strive to get it in in Phase 1 of the integration, since
it is very beneficial to oVirt.

> 
> mike - what's the plan for ovirt-node support for qunatum agents?

The plan for phase 1 is stated there: 
"No support for pre-built ovirt-node (or RHEV-H)."

> 
>  > Current implementation will be done by hooks.
> 
> iiuc, this is a temp solution, and you plan to make it a fully featured
> item later on as the integration matures?

Yes this is only as an initial step, as we don't want to define a concrete
contract yet with VDSM this seems like a reasonable approach.

> 
> > Each network can be provided either by oVirt or by the external provider.
> 
> did we look at our code to understand what it would mean to refactor the
> ovirt network code as an external provider as well (doesn't have to be
> out of process, just generalize/modularize our code and not have private
> cases) - there is work for doing something similar for the pluggable
> scheduler, first refactoring the existing scheduling code out as well.

Currently there hasn't been much work in that direction, however we need to
consider the fact that Quantum (and many other external providers) will be
providing us with VM network capability only, so perhaps only this part
can be done as a "provider".

However, we should take note that current oVirt implementation for VM
networks is more flexible than that of Quantum, so having it as "provider"
could limit that flexibility.

> 
> > If a network is externally provided, it will not be editable in oVirt,
> > since the external provider is responsible for managing the actual network
> > configuration.
> 
> unless we add support for editing it via the external provider (like we
> support adding an external network and importing it from the external
> provider)?

We could add such support, but it is not planned for Phase 1 currently..

> 
> > This effectively means that the user is responsible for quantum
> > availability on all the hosts in a given cluster the external network is
> > attached to.
> 
> we can consider an external provider to also have a health check api,
> then engine can alert on that service not being available, which is what
> the admin will expect.

As we are trying not to commit for VDSM API for Phase 1, I reckon this can
be done in a later phase.

> 
> > Port mirroring is not available for virtual NICs connected to external
> > networks.
> 
> is this inherent, or until external providers add support for it/

I don't know of such support being available in Quantum networks.
If it would be possible we will of course strive to add it.

> 
> > Block editing provider API address if there are networks imported from it.
> 
> why? what if i changed its dns name, but it is still the same service?

I will delete this.

> 
> > Integration will be done at this phase for running virtual machine only, so
> > other operations (hot-plug, rewire, etc) will not be supported for
> > externally provided networks.
> 
> just wondering - how is hot plug different from run vm, now that we have
> pre device custom properties (since hooks are used)?

I will update this.

> 
> > Configuring keystone adds an additional dependency for the administrator to
> > handle.
> 
> I think a global config should be fine for now, and in any case, this is
> needed for the glance integration as well

Yes I agree.

> 
> > Libvirt bug still not solved, Linux Bridge support requires quantum hack
> > (or push as a fix for the agent)
> 
> bug number?

https://bugzilla.redhat.com/893576
It is listed in the feature page as a dependency, but I will add a link here.

> 
>  > Future phases
> 
> I think IPAM, L3 and security groups are interesting to try and leverage
> quantum features

I will add a section with these directions.

> 
> Thanks,
>     Itamar
> 
>