On Fri, Aug 23, 2019 at 6:41 PM Michal Skrivanek <
[email protected]> 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
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/[email protected]/message/YN5DG74USYUYIVDHD2AURP2E7PDDNBTF/

Reply via email to