On Tue, Dec 15, 2015 at 5:12 PM, Francesco Romani <from...@redhat.com> wrote: > Hi all, > > I'm happy to start a weekly summary of what's going on on virt's world (VDSM > edition). > > General topics > * I've got some mixed feedback about my Vm-on-a-diet effort. I still believe > that fat trimming > is a worthwhile goal per se, but I'm willing to adapt the strategy > responding to the comments, > so we will focus on virt-specific topics. > * As consequence of the above, I'm focusing on the last bits of device > fixing, which involves > - fixing all device to update themselves from libvirt XML after domain > boot, instead using > all the getUnderyling* methods
+1 > - switch the devices related code to use Etree instead of minidom. This > will involve changes to > the domain_descriptor. > I estimate this task will still trim ~600 lines out of vm.py, so it still > somehow gets some > size trimming done, albeit not intensive as planned. > This is a complex topic, will post plan and ideas on a separate mail +1, lets kill minidom entirely. > * Finally, some series are still worth pushing forward, see below. > > Patches in need of attention > * topic branches > - mpolednik started a much needed cleanup and fixing of fake_qemu and > fake_kvm code, with the ultimate goal to move all > the remaining bits into the faqemu hook, and to make it useful on ppc64. > Lots of refactoring is needed to support this change, and that produced > https://gerrit.ovirt.org/#/q/topic:cpuinfo I reviewed the first and biggest patch. I like the idea, but I think we should make some small changes before it, for example removing of the POWER constant. having constats of the same group using different types is a horrible idea. X86_64 = "x86_64" POWER = ("ppc64", "ppc64le") Before we do big and risky cleanups, we should do small and safe cleanup like unifying the constants. Another issue, there is no point in moving caps.Architecture to cpuarch.Architecture. In the caps module, this class used to group the constants like X86_64. the cpuarch module is replacing the Architecture class, so we would like one patch moving the constants and eliminating the useless class. Having too patches, one moving the class and the other eliminating it is wasting reviewers time. I'm waiting for more reviews from the virt guys on this topic. > - we want to improve the reporting in case of migratio aborted. The ultimate > goal is to let Engine (thus the User) > know why a migration failed. Why the reason is not available? Maybe this is another use case for the jobs module? Keep a job for each migration, report job status and errors? > To export this information, however, we need some cleanup before. Hence: > > https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:migration_report > - last and less urgent: here's some cleanup about existing getUnderlying* > methods of Vm class, preparing > the last step of the big vmdevices split. I believe this is useful anyway > > https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:vm-trim-stage-1-p4-pre > > * single patches > - https://gerrit.ovirt.org/#/c/46846 > this is the first of a series aiming to improve migration support in 4.0. > Probably worth merging all together, > even though this one seems ready for broader review to me. > - https://gerrit.ovirt.org/#/c/49173/ > Notified just to raise awareness, still working on ensuring backward > compatibility and smooth upgrade > - https://gerrit.ovirt.org/#/c/48672 > v2v xen support > - https://gerrit.ovirt.org/#/c/49951/ > OVA support improvements. Worth a look, but note that we are working toward > a split of this big patch > - https://gerrit.ovirt.org/#/c/49636 > V2V refactoring, also almost ready We need more reviewers for the v2v patches. > - https://gerrit.ovirt.org/#/c/49570/ > still in the context of migration enhancements. We want to throttle > incoming migrations, to do so we want > to use a sempahore which needs to be held by the creation thread until VM > is created. > This helper makes this possible, using an uniform interface for both this > case and the common, simpler case. This code is too abstract, we should have something that is more about incoming migration, not about running async tasks with resources. > > That's all for now, as usual, reviews welcome! :) > > -- > Francesco Romani > RedHat Engineering Virtualization R & D > Phone: 8261328 > IRC: fromani > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
