----- Original Message -----
From: "Francesco Romani" <fromani(a)redhat.com>
To: devel(a)ovirt.org
Sent: Tuesday, November 24, 2015 11:51:10 AM
Subject: [ovirt-devel] [vdsm][oVirt 4.0] trimming down vm.py, stage 1
[...]
We have roughly five weeks left until the end of the year.
Sounds like a good timespan for the first stage, and I'm aiming for go down
under
the 4000 line mark.
So we have roughly 1200 lines to eliminate somehow.
This is the initial plan I'm thinking off, in expected increasing difficulty
level, from easies to hardest:
And here's the first status update
1. LiveMergeCleanupThread:
Chance to break things: minimal
- roughly 120 lines (10% of the goal)
- can be moved verbatim (cut/paste) elsewhere, like vdsm/virt/livemerge.py,
fixing only import paths.
Patch ready and not published. I was thinking about moving more code in the newly
created livemerge.py, but not sure about the partitioning. I'll just push
the patch so we can discuss there.
2. the findDrive* family of functions:
Chance to break things: minimal/very low
- roughly 50 lines (~4% of the goal)
- can be moved with minimal changes elsewhere, like
vdsm/virt/storage/????.py,
Done in
https://gerrit.ovirt.org/#/c/49209/
3. the getConf* faimily of functions:
Chance to break things: medium-to-high in the 3.x branch, low on 4.x because
we drop backward compat.
- roughly 110 lines (~9% of the goal)
- just drop them for 4.0!
- alternatively, need to figure out a proper place, maybe a new module?
Just dropped in
https://gerrit.ovirt.org/#/c/49173/
The patch is quite large but simple, in the end all the code is guarded
by a couple of bug if()s.
The only concern is we break compatibility with older Engines, so maybe
merge this later in the development cycles.
Except for maybe some glitches, I don't expect further work here (of course
except verification!)
4. the Devices/VM setup bits
All scatthered through vm.py (e.g. _buildDomainXML, DeviceMapping table)
Chance to break things: medium-to-low, depends on individual patches
- all summed up, roughly 200 lines (~18% of the goal)
- need serious cleanup
- no definite plan
- mostly is cut/paste or transform Vm methods into functions
Not tackled yet
5. the getUnderlying* familiy of functions:
Chance to break things: low (maybe medium on some cases, to lean on the safe
side)
- roughly 550 lines (~46% of the goal)
- easy to test (just run vms!)
- can be moved in the devices/ subpackage with some changes.
- require further work in the area to properly integrate this code in the
device objects
- more work is planned in this area, including move from minidom to
ElementTree
Not tackled yet
Bests,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani