OpenStack Quantum integration feature page for 3.3

[Itamar Heim]

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
>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

A few questions/comments (inlining relevant parts of 
http://www.ovirt.org/Features/Detailed_Quantum_Integration)

> 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.

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

 > 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?

> 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.

> 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)?

> 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.

> Port mirroring is not available for virtual NICs connected to external networks.

is this inherent, or until external providers add support for 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?

> 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)?

> 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

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

bug number?

 > Future phases

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

Thanks,
    Itamar