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.*
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
