[ovirt-devel] Vdsm sync 19/1

[Yaniv Bronheim]

Hi all,

(Participated: Piotr, Francesco, Adam, Nir, Edy and I)

We discussed about the following topics:

Python3  - terminating contextmanager is ready
https://gerrit.ovirt.org/51407  - this allows us to remove deathSignal
usages and safely kill processes on failures.
Francesco already covered one location (https://gerrit.ovirt.org/#/c/52349/)
this week I hope we'll *start* the work to cover the rest of the code as
follow:
vdsm/storage/mount.py
vdsm/storage/iscsiadm.py
vdsm/storage/imageSharing.py
vdsm/storage/hba.py
vdsm/storage/blockSD.py
vdsm/v2v.py
If any gaps or dependencies are raised I asked to state it in python3 work
sheet (
https://docs.google.com/spreadsheets/d/180F-C1jU54ajUn7TuR-NwrKRZY1IiZI1Z8U5HWbvEvM/edit#gid=0)
and we'll discuss it in next call.

next will be to remove all deathSignal usages - currently there are
redundant place where its being used that can be removed today:
lib/vdsm/qemuimg.py
vdsm/storage/curlImgWrap.py
vdsm/storage/storage_mailbox.py
vdsm/storage/misc.py
vdsm/API.py

Hopefully patches for that will be posted during the week.
Next step will be to use Popen where cpopen is not available (
https://gerrit.ovirt.org/48384) and we'll move forward with migrate more
tests to python3.

- Vdsm communicate - we did a little summary about what was explored and
what we want to have. It was only a discussion to see where we're heading.
 External Broker - In the past we checked Cupid (IMQP) and ActiveMQ (STOMP).
In cupid we found many bugs and gaps, we thought about using only the
client of it for point to point communication, but then found it too
complex. actionMQ is in java and found to be too slow and consume a lot of
memory so we thought about having only one instance in cluster, or maybe
run it in external host that doesn't run vdsm, or put it with the engine
host - for that we will need to change all "host lifecycle" that we have
today so we left it as well (piotr, fill me up if I missed something)
We have implementation for "mini borker" as part of vdsm which perform what
we need to run it as external process to vdsm and forward messages to
clients. there are alternatives as ZeroMQ that we can explore.
Bottom line - we want to approve the communicate inside the host, between
vdsm to other services such as supervdsm, mom and maybe later we'll split
the current implementation of vdsm to more services that will run in
parallel (such as vm monitoring, vdsm-storage and so on. For that we can
use dbus, multiprocessing(uds), or some kind of a broker.
This leaded us to talk about service separation which we want to design
soon.

- Vdsm contract - Piotr sent yaml schema plan in
https://gerrit.ovirt.org/#/c/52404 - please ack that you agree with the
concept. Piotr moves on with that and start to migrate all verbs to that
form. For next version we shell have both types of schema available, and
start to add new verbs and events structures in the new yaml format.

- Exceptions - Nir raises that we should define Virt specific exceptions -
Francesco can elaborate about the plans next week.

- Network updates - Edy checks how to improve network configuration time.
Currently vdsm modifies ifcfg files, which after changing them it takes
time for the update to catch.

Interesting call guys, I encourage more developers to participate, listen
and influence vdsm 4.0 directions.

See you next week.

-- 
*Yaniv Bronhaim.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160120/1f2593c9/attachment-0001.html>