On 04/29/2012 01:41 PM, Gary Kotton wrote:
Hi,
As part of a POC we have integrated Quantum
(http://wiki.openstack.org/Quantum) into oVirt (http://www.ovirt.org/).
This has been tested with the OVS and Linux Bridge plugins.
The details of the integration can be found at -
https://fedoraproject.org/wiki/Quantum_and_oVirt.
Any comments and suggestions would be greatly appreciated.
Thanks
Gary
Thanks Gary - some questions:
1. you are using the term 'user' for both an end-user and an admin. I
think admin is more appropriate in most places.
2. host management --> interface
2.1 you are suggesting to remove the vlan field with a fabric field?
are we sure this is something which shouldn't be presented in the main
view and only via extended properties?
2.2 is the fabric really a host interface level property, or a cluster
wide property (would same logical network be implemented on different
hosts in the cluster via both vdsm and quantum)?
would live migration work in same cluster if one host has qunatum fabric
and another vdsm fabric for same logical network?
2.3 you are describing the subtab of an interface, and mention a qunatum
pull down menu. is this in the subtab? in a dialog?
UI mockups are needed here.
2.4 also, is this pulldown correct at host level or cluster level (would
live migration work between hosts implementing different plugins for
same logical network in same cluster?)
on to backend:
3.1 "The Quantum Service is a process that runs the Quantum API web
server (port 9696)"
how is authentication between engine and quantum service is done (we
have a client certificate for engine which qunatum can verify i guess)
3.2 is there a config of the quantum service uri? should it be a single
instance or a per DC property?
(it sounds like a per DC property, can be a future thing)
3.3 network creation
semantics: we create a network at DC level. we attach it at cluster
level. the UI allows you to "create at DC and attach to cluster" at
cluster level.
3.3.1 what if i create a network with same VLAN in two DC's? what if we
attach same logical network to multiple clusters - each will create the
logical network in qunatum again?
3.3.2 what if the qunatum service is down when engine performs this
action or quantum returns an error?
3.3.3 each creation of a DC creates a rhevm network - I assume these are
not created, since "no host in a cluster in the DC yet"?
3.3.4 what happens on moving of a host to another cluster, or moving of
a cluster to another DC (possible if it's DC was removed iirc).
3.3.5 shouldn't this be limited to vm networks, or all networks are
relevant?
3.3.6 what if the host with the qunatum fabric is in maint mode?
3.3.7 could a host with qunatum fabric have a VDSM fabric on another
interface (for vm neworks? for non-vm networks)?
3.5 network deletion (detach network from a cluster)
3.5.1 what happens if qunatum is down or returned an error?
3.6 vm creation
3.6.1 what about moving a VM from/to a cluster with a quantum fabric?
3.6.2 what about import of a VM into a cluster with a qunatum fabric?
3.6.3 you have vm creation/removal - missing vnic addition/removal
3.6.4 worth mentioning qunatum doesn't care about the vnic model? about
the mac address?
3.7 vm start
3.7.1 why is the plugin parameter required at vm start? can multiple
plugins be supported in parallel at vdsm/host level or by the quantum
service?
3.7.2 aren't network_uuid and port uuid redundant to attachment uuid (I
assume qunatum service knows from attachment the port and network) - i
have no objection to passing them to vdsm, just trying to understand
reasoning for this.
I am missing what happens at vdsm level in this point (even after
reading the matching vdsm part)
3.8 vm suspend/resume (it's fine to say it behaves like X, but still
need to be covered to not cause bugs/regressions)
3.9 vm stop
3.9.1 need to make sure vm stop when engine is down is handled correctly.
3.9.2 what happens if qunatum service is down? unlike start vm or
network creation the operation in this case cannot be
stopped/rolledback, only rolled forward.
3.10 hot plug nic?
3.11 vm migration
3.11.1 ok, so this is the first time i understand hosts can be mixed in
same cluster. worth specifying this in the beginning (still not clear if
mixed plugins can exist)
3.11.2 afair, we don't deal with engine talking to both hosts during
live migration. only to host A, who is then communicating with host B.
so why not always have the VM configuration at vm start (and hot plug
nic) have the quantum details so live migration can occur at will
without additional information?
3.11.3 "In order to implement the above a REST client needs to be
implemented in the oVirt engine. "
did not understand this statement - please elaborate.
4. host management
4.1 deployment
we do not deploy packages from engine to hosts, we can install them from
a repo configured to the host. but this is done today only as part of
initial bootstrap/installation of host.
also, it is not relevant for ovirt node which is 'firmware' like.
any reason to not require the 'plugin installation packages' at vdsm rpm
level for plugins we think are good enough to use (until then,
responsibility to deploy them is of admin)
(what are plugin level packages at host level - aren't these the agents?)
4.2 plugin configuration
per DC? per cluster? per host? per plugin? please provide more details
here on configuration details expected and flow of when they are
configured and when they are expected to change?
I think this will merit a per 'ovirt supported' qunatum plugin to see it
works in a way we can use.
4.3 connectivity
again, this requires more details. if needed per plugin.
what is expected? how authentication/encryption happens? what iptables
rules need to change in engine/host if at all, etc.
I'm fine with this being 'direct access to db from hosts' for POC level
of patches, but not for something we actually merge/provide support for
later.
5. VDSM
5.1 s/The agent packe/The agent package/ ?
5.2 "The agent package can and may be received from the oVirt Engine or
can be downloaded via RPM's"
see 4.1 above - we don't deploy rpm's/code on the fly today.
5.3 "n addition to the treatment below VDSM should also maintain a
health check to the Quantum agent"
what if the restart didn't help? how should ovirt treat the host wrt
networking? to running VMs? to ability to live migrate VMs from the host
if needed?
5.4 "Logical Network Management"
please see 3.11 above - we would want live migration to not require
additional information, so details should be available even if not
immediately acted upon.
5.5 "The tap device created uses an "ethernet" network device. This
means that the creation of the libvirt XML file is a bit different."
5.5.1 does this impact stable device addresses somehow?
5.5.2 how is live migration possible if the libvirt xml to a non quantum
host is different (or is this the binding part only)?
5.6 I assume libvirtvm.py is part of vdsm.
is quantum.py part of quantum code base or vdsm codebase (it sounds like
it should be part of quantum code base)?
so how exactly the rpm for this would look like? deploy it to
/xxx/qunatum and have it add a symbolic link to it from vdsm paths?
5.7 "When a communication channel is established between VDSM and the
oVirt engine. The VDSM host should notify the oVirt Engine of the
Quantum fabric that is supported."
how does vdsm goes about detecting an agent is installed exactly?
(especially since deployment wise, most likely is all agents would be
deployed via rpm requirements?)
is any agent a service at host level rather than code only?
is there a scenario where a vdsm level plugin isn't required?
6. open issues
6.1 worth mentioning if any are in the works
6.2 specifying the vlan from ovirt engine is not a gap?
6.3 ok, so this is the first time "no multiple plugins" is mentioned
("Non-uniform technology"). but it sounds like the approach in the wiki
assume it is/will be possible to have multiple technologies
(agents/plugins) going forward?
6.4 need to discuss which of the open issues should block going forward
with merging of code, and expected timeframe for resolution of some of them
7. other questions/items (some mentioned above as well)
7.1 please add ui mockups, db scheme changes and REST api changes
7.2 i'm missing the deployment flow:
- user install engine. is quantum a separate install or bundled going
forward?
- any configuration items by user at this point? what are they?
- what rpms are deployed at host level? what configuration do they need
- communication channels and their security are a must to understand
7.3 upgrade path / compatibility levels this is relevant to?
7.4 monitoring flow - how is monitoring/state of a host is affected by
quantum service being down, communication problem from host to (where
actually?)
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
