On Tue, Feb 23, 2016 at 6:30 PM, Yaniv Bronheim <ybronhei@redhat.com> wrote:
(Nir, Adam, YanivB, Dan, Milan, Piotr, Francesco, Martin Polednik, Edward)

- Some of us started to work on refactoring for python3, basic file movements and improving testings 

 - We added functional tests to check-merged automation script - currently, for some reason, it doesn't run tests that require root. I'm on it.

 - if anyone know that their functional tests work good please add them to the list 
so they will run each merge

 - moving code from supervdsmServer to supervdsm_api - follow https://gerrit.ovirt.org/53496 and move also virt, storage and sla part

 - Nir says to use the weekly contact from storage team to help with verification about storage code changes- I'll try to reach them next week to test direct LUN

  - I also wanted to use lago basic_suite (ovirt-system-tests) to run full flow from specific vdsm commit - but the infrastructure for that requires many manual steps and its not easy as I expected it to be.

- moving code from vdsm dir (/usr/share/vdsm/) to site-packages/vdsm (by moving them to lib/vdsm) - this is required to avoid relative imports which are not allowed in python3 - storage dir is the main gap we currently have.

- python-modernize - Dan uses it for network tests dir and encourage us to start running it for our parts

- there are some schema changes, mostly removal parts that Piotr posted as part of converting to yaml structure. this code needs to be reviewed
- Nir asks to keep the current API order instead of sorting by names 
- Nir concerns about yaml notation looks for a list with single element
- split the yaml schema to several files is complex but nir asks to see if its possible

- storage team mainly works hard on SDM patches

- Edward works on splitting network tests between unit tests and integration tests which do environment setup changes

- we currently don't run the slow test automatically
- we might want more "tags" for tests such as SlowTests, StressTests

And the most important issue - vdsm for ovirt 4.0 will keep only 3.6 backward compatibility - if you don't agree with that statement, please say why ... but as far as we see it, this is the direction and we already removing 3.5 stuff.

If a customer has 3.5 level cluster with all hosts on RHEL 7, why would we break compatibility? Need to understand the cost here.
The very least is to allow live migration .
Y.


Thanks all for participating,

--
Yaniv Bronhaim.

_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel