[ovirt-devel] [vdsm][oVirt 4.0] trimming down vm.py, stage 1

[Francesco Romani]

----- Original Message -----
> From: "Francesco Romani" <fromani at redhat.com>
> To: devel at 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