On Fri, Aug 23, 2019 at 6:41 PM Michal Skrivanek < michal.skrivanek@redhat.com> wrote: ...
I agree about the speed, OST is awfully slow, almost unusable. But other than that, not really, I discourage you from neglecting functional fixes and just focuse on unit tests. It is important to fix actual functional problems
We are focusing on small and fast functional tests doing real flows with (mostly) real storage. I think this give be the best value. Being able to verify changes in seconds means you can move fast - safely. The most important actual issue we have now is tests failing on pyhton 3, for example block storage tests: https://gerrit.ovirt.org/q/topic:py3-blocksd When these tests will pass, there is a chance that block storage will work in OST. A bigger problem is code without any tests like the tasks framework, SPM flows and legacy storage flows. We work now on the tasks framework: https://gerrit.ovirt.org/q/topic:py3_task We also worked on the outOfProcess module which is the foundation of all file based storage domains: https://gerrit.ovirt.org/q/topic:py3-oop This work reveled 2 bugs in ioproess, one fixed now: https://gerrit.ovirt.org/q/topic:ioprocess_access
Coincidentally, just now I got a working OST on py3/RHEL8 just with a couple of workarounds/skips. So we should soon be able to have this (slow) safeguard in place and we’ll be able to eliminate py2/el7 code.
We need to keep python 2.7 code until we finish porting to python 3, and maybe later. It will be hard to support 4.3 if master code is not compatible with python 2. Nir