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