Heads up: Engine 3.6.5 branching out next week
by Tal Nisan
Hey everyone,
Around mid next week Engine 3.6.5 will be branched out from the
ovirt-engine-3.6 branch.
This gives the teams a few days of grace to be able to close 3.6.5 issues
with a single backport so now will be a good time to go over the patches in
the branch and review/verify so they can get merged.
Right after the branching out all 3.6.5 patches will have to be backported
both to the 3.6 branch and the 3.6.5 branch whereas 3.6.6 patches will be
backported to the 3.6 branch only.
Another heads up on a related issue: there are currently 38 open patches in
the 3.6 branch some of which date as far as January.
As this clutters my everyday work on the branch, right after branching out
I'm going to clear out stale patches and I'm going to keep abandoning
patches in the stable branch that are stale for too long.
Bear in mind that in 99.9% of the cases there is no reason for a patch to
be open on the stable branch for more that 2 weeks after it's merged on
master.
8 years, 1 month
[vdsm][virt] what's new in virt (20151215)
by Francesco Romani
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
- 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
* 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
- 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. To export this information, however, we need some cleanup before. Hence:
https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic...
- 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...
* 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
- 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.
That's all for now, as usual, reviews welcome! :)
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
8 years, 1 month
removing old ovirt-engine unit tests jobs
by Eyal Edri
Hi,
I'd like to remove the following jobs from CI [1], since they are not
adding any benefit over existing logic provided by the standard ci jobs
(i.e checkstyle & unit tests already run there).
Pros from removing:
---------------------------
- reduce time needed to wait on patch verification
- reduce load on jenkins
- reduce possibility of false positive errors (since they are not
running on mock)
- reduce load on jenkins in general & maintainability
Possible cons:
------------------
- output on unit tests failure might be not nice as existing jobs, but
will still provide the relevant error. there is an open ticket on adding
support for UI on STD ci, so it will there in the future.
If I won't get any rejections or justified concerns on this thread, I will
start with disabling them
and if all goes well removing them after 1 week.
[1]
ovirt-engine_3.6_style_gerrit
ovirt-engine_master_style_gerrit
ovirt-engine_3.6_unit-tests_gerrit
ovirt-engine_3.6_unit-tests_merged
ovirt-engine_master_unit-tests_gerrit
ovirt-engine_master_unit-tests_merged
--
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
8 years, 1 month
oVirt Integration Development Team weekly status - 2016-03-21
by Sandro Bonazzola
- *oVirt Integration Development Team weekly status - 2016-03-21*
-
- oVirt integration open bugs:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=classification%3Aovir...
- 4.0
- master is now stable enough to be tested
- working with Node team to streamline NGN build in jenkins
- working with Node team supporting NGN cockpit plugins
- working with Infra team on packaging new dashboard nodejs based
packages
- working with Storage team packaging ovirt image uploader daemon
- working on migration path from el6 3.6 to el7 4.0
- ovirt-log-collector works again with Fedora on master
- 3.6:
- Closed 3.6.4 pending bugs
- Released oVirt 3.6.4 RC1
- Announce:
http://lists.ovirt.org/pipermail/announce/2016-March/000238.html
- Release notes: http://www.ovirt.org/release/3.6.4/
- Fixing 3.6.5 bugs
- Preparing to release 3.6.4 RC2
- Infra:
- Fixed guest agent jenkins jobs
- Fixed repoclosure issues on 3.6 snapshot
- CentOS Virt SIG:
- Next meeting scheduled on Tue 22nd 16:00 CET
- LINK: Roadmap and packages list:
http://wiki.centos.org/SpecialInterestGroup/Virtualization/Roadmap
- LINK: http://wiki.centos.org/HowTos/oVirt
- Meeting minutes will be available on
https://www.centos.org/minutes/2016/
*Team updates*
- Didi
- Worked on several bugs/changes, mainly in otopi
- Ido:
- getting familiar with Hosted engine installation
- getting familiar with Lago installation
- Lev:
- working on few bugs, mostly on ovirt-live
- Rafael:
- Working to split engine-backup from ovirt-engine-tools package
- Working on configuration query tool for otopi
- Worked on 3.6.4 RC1 release
- Sandro:
- Working with Rafael and Simone on 3.6.4 RC1 release
- Working with Fabian on ovirt-release for Next Generation Node
- Finishing presentation for Incotro DevOps @ Bologna
- Simone:
- Worked on hosted-engine compatibility issues with python SDK on
master
- Adding an additional CLI option to let the user pass a custom
vm.conf on hosted-engine
- Let user add a 3.6 hosted-engine host on a system that was started
with 3.4 by scanning all the volume uuids on disk (at 3.4 time
they wasn't
in the answerfile)
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
8 years, 1 month
Access to memory snapshots?
by Matt Mossholder
Hi everyone!
I am working on developing a plugin for the cuckoo sandbox (
http://cuckoosandbox.org), that will allow users to select oVirt as a
virtualiztion solution. I have it working, for the most part, but one area
where I need some guidance is in retrieving memory images. I know that
when you take a snapshot, you can request that the memory be stored as
well.
My issue is that I don't see a way to retrieve the memory, so that it
can be feed into analysis tools like Volatility (
http://www.volatilityfoundation.org/). Does anyone have any pointers for me?
Thanks!
--Matt
8 years, 1 month
