March 2016 - Devel - oVirt List Archives

Progress report on Vdsm Debian packaging
by Milan Zamazal 21 May '16

21 May '16

I made progress with Debian packaging of Vdsm. We have all the supporting packages (cpopen, ioprocess, mom, pthreading, safelease, sanlock) in Debian now. I took over maintenance of sanlock Debian package, updated it and made a lot of fixes, including preparing the previously unavailable python-sanlock package. As for Vdsm itself, the package can be installed now and Vdsm can be started. It doesn't work with Engine, which is no big surprise. We can't simply reinstall a Debian host from Engine, so we need to find some way how to initialize the host properly. And it's likely there are distribution specific pieces inside Vdsm and elsewhere. All the package sources, including not yet uploaded Vdsm package, are available on http://git.debian.org . How you can help: - Obviously, we need to make Vdsm hosts working, so any help in this area is welcome. - Reviewing and testing Vdsm Debian package (without actually using it) is also very helpful, I'm sure there are things to fix or improve. - There are some Lintian warnings in the packages, fixing them would be nice. - We should also review Debian patches in the packages, decide what should be changed upstream and report it. - You can help with anything else you consider useful.

4 6

Vdsm api package
by Nir Soffer 29 Apr '16

29 Apr '16

Hi all, In the Vdsm call, we discussed a way to expose vdsm errors to its clients (e.g, engine, hosted engine agent/setup). The idea is to have a vdsmapi package, holding: - errors.py - all public errors - events.py - all events sent by vdsm - client.py - library for communicating with vdsm - schema.py - the client will use this to autogenerate online help and validate messages - schema.yaml - we probably need several files (gluster, events, etc.) This will allow other projects talking with vdsm to do: from vdsmapi import client, errors ... try: client.list(vmId="xxxyyy") except errors.NoSuchVM: ... (this is a fake example, the real api may be different) Engine can build-require vdsmapi, and generate java module with the public errors from vdsmapi/errors.py module, instead of keeping this hardcoded in engine, and updating it every time vdsm adds new public error. Vdsm will use this package when building response to clients. Edi was concerned about sharing the errors module, so maybe we need a package: vdsmapi/ errors/ network.py virt.py storage.py gluster.py We can still expose all the errors via errors/__init__.py, so clients do not have to care about the area of the application the error come from. Thoughts? Nir

5 7

Maintenance Notification: *.ovirt.org Services Today at 18:00 IST (17:00 CET)
by Anton Marchukov 31 Mar '16

31 Mar '16

Hello All. Today at 18:00 IST (17:00 CET) we plan to do hardware upgrades at the datacenter where most of ovirt.org services are hosted. Although we plan to minimize the services downtime, it might still be needed. This does not affect gerrit.ovirt.org but may impact jenkins and other services. The maintenance window is scheduled to last for 2 hours. Anton. -- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat

1 0

are there any ways to disable the log file?
by zhukaijie 31 Mar '16

31 Mar '16

"Since oVirt 3.5.0 (VDSM 4.16.0), VDSM does not enable the overly verbose libvirt debug logs automatically." from http://www.ovirt.org/develop/developer-guide/vdsm/log-files/. So my problem is. Each running VM has it's command line logged in /var/log/libvirt/qemu/${vmname}. And now I'd like to disable this log function, that is to say, not to record the QEMU command line of VM. So could oVirt or VDSM disable this qemu command line log file just like libvirt debug logs? Thank you.

2 1

[ANN] oVirt 3.6.5 First Release Candidate is now available for testing
by Sandro Bonazzola 31 Mar '16

31 Mar '16

The oVirt Project is pleased to announce the availability of the First Release Candidate of oVirt 3.6.5 for testing, as of March 31st, 2016 This release is available now for: * Fedora 22 * Red Hat Enterprise Linux 6.7 * CentOS Linux 6.7 (or similar) * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 22 This release is also available with experimental support for: * Debian 8.3 Jessie This release candidate includes the following updated packages: - ovirt-engine - ovirt-engine-reports - ovirt-engine-sdk-python - ovirt-engine-sdk-java - ovirt-hosted-engine-ha - ovirt-hosted-engine-setup See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO will be available soon [2]. * Mirrors[3] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 3.6.3 release highlights: http://www.ovirt.org/release/3.6.5/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/3.6.5/ [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Re: [ovirt-devel] virt-v2v become zombie via python cpopen on error
by Michal Skrivanek 31 Mar '16

31 Mar '16

> On 30 Mar 2016, at 11:49, Richard W.M. Jones <rjones(a)redhat.com> wrote: > > On Wed, Mar 30, 2016 at 12:19:35PM +0300, Shahar Havivi wrote: >> Hi, >> >> We encounter a problem in VDSM project that virt-v2v become zombie task while >> importing vm from vmware. >> When virt-v2v is in 'copy disk' mode and we someone deletes the vm at vmware >> the process hang in read() method, >> I am pretty sure that its not virt-v2v problem because when I run it from the >> shell virt-v2v exit with an error, still maybe someone have an idea.... >> >> I wrote a small python script that encounter the problem: >> >> ---------------------------------------------------------------------------- >> from cpopen import CPopen >> >> env = {'LIBGUESTFS_BACKEND': 'direct'} >> cmd = ['/usr/bin/virt-v2v', '-ic', >> 'vpx://....', '-o', >> 'local', '-os', '/tmp', '-of', 'raw', '-oa', 'sparse', >> '--password-file', '/tmp/passwd', '--machine-readable', 'bbb'] >> p = CPopen(cmd, env=env) >> while p.returncode is None: >> c = p.stdout.read(1) >> print c >> ---------------------------------------------------------------------------- > > An actual zombie task? That would indicate that the parent process > (your Python program) wasn't doing a wait system call. > > I downloaded the cpopen-1.4 program, and it doesn't appear to call any > of the wait*(2) system calls anywhere, so that could be the problem. I suppose the cpopen parameters are not alright…I’m sure vdsm developers can help with that. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v

4 4

oVirt Node Next builds are currently broken
by Fabian Deutsch 31 Mar '16

31 Mar '16

Hey, just a quick heads up that our oVirt Node Next jenkins builds are currently broken. Some of the symptoms are that the installation is failing and that no new updates are available. We are working on a solution. - fabian

1 0

Get Involved with oVirt project! Spring edition
by Sandro Bonazzola 30 Mar '16

30 Mar '16

Hi, Have you got some free time and do you want to get involved in oVirt project? Do you like the idea of having fresh disk images of recent distribution in oVirt Glance repository? You can help us by testing existing online images ensuring they works with cloud-init or creating one yourself and report your success to devel(a)ovirt.org. We'll be happy to upload the images once these are ready. Do you like Debian and do you have some programming or packaging skills? Help us getting Vdsm running on it! We work on inclusion of Vdsm into Debian. We need to test and fix Vdsm Debian packages to make them working before the next Debian freeze. You can find all current Debian work (Vdsm and related packages) in Debian git repositories [10]. You can follow the progress and participate on oVirt development mailing list [11]. Here are some bugs you can try to help with: 1159784 ovirt-engine Documentation NEW [RFE] Document when and where new features are available ... 1074301 ovirt-engine-cli RFEs NEW [RFE] ovirt-shell has no man page 772931 ovirt-engine-reports RFEs NEW [RFE] Reports should include the name of the oVirt engine 1120585 ovirt-image-uploader Documentation NEW update image uploader documentation 1120586 ovirt-iso-uploader Documentation NEW update iso uploader documentation 1120588 ovirt-log-collector Documentation NEW update log collector documentation 1237132 ovirt-engine Setup.Engine NEW [TEXT] New package listing of engine-setup when upgrading... 1115059 ovirt-engine General ASSIGNED Incomplete error message when adding VNIC profile to runn... Are you great at packaging software? Do you prefer a distribution which is currently unsupported by oVirt? Do you want to have packages included in your preferred distribution? Help getting oVirt ported there! Fedora: http://lists.ovirt.org/pipermail/devel/2015-September/011426.html CentOS: https://wiki.centos.org/SpecialInterestGroup/Virtualization Gentoo: https://wiki.gentoo.org/wiki/OVirt (GSoC: https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2016/Ideas ) Debian: http://www.ovirt.org/develop/release-management/features/debian-support-for… Archlinux: http://www.ovirt.org/develop/developer-guide/arch-linux/ OpenSUSE: https://build.opensuse.org/project/show/Virtualization:oVirt Do you love "DevOps?", you count stable builds in jenkins ci while trying to fall a sleep? Then oVirt infra team is looking for you!, join the infra team and dive in to do the newest and coolest devops tools today! Here are some of our open tasks you can help with: https://ovirt-jira.atlassian.net/secure/RapidBoard.jspa?rapidView=6 You can also help us by sharing how you use oVirt in your DevOps environment (please use [DevOps] in the subject). You can check out more docs on the DevOps side of oVirt in [12][13] You don't have programming skills, not enough time for DevOps but you want still to contribute? Here are some bugs you can take care of, also without writing a line of code: https://bugzilla.redhat.com/buglist.cgi?quicksearch=classification%3Aovirt%… Do you prefer to test things? We have some test cases[5] you can try using nightly snapshots[6]. Do you want to contribute test cases? Most of the features[7] included in oVirt are missing a test case, you're welcome to contribute one! Do you want to contribute artworks? oVirt Live backgrounds and covers, release banners, stickers, .... Take a look at Fedora Artworks[9] as an example of what you can do Is this the first time you try to contribute to oVirt project? You can start from here [1][2]! You don't know gerrit very well? You can find some more docs here [3]. Any other question about development? Feel free to ask on devel(a)ovirt.org or on irc channel[4]. You don't really have time / skills for any development / documentation / testing related task? Spread the word[8]! Let us know you're getting involved, present yourself and tell us what you're going to do, you'll be welcome! [1] http://www.ovirt.org/develop/ [2] http://www.ovirt.org/develop/dev-process/working-with-gerrit/ [3] https://gerrit-review.googlesource.com/Documentation [4] http://www.ovirt.org/community/ [5] http://www.ovirt.org/develop/infra/testing/ [6] http://www.ovirt.org/develop/dev-process/install-nightly-snapshot/ [7] http://www.ovirt.org/develop/release-management/features/ [8] http://www.zdnet.com/article/how-much-longer-can-red-hats-ovirt-remain-cove… [9] https://fedoraproject.org/wiki/Artwork#Resources [10] http://git.debian.org [11] http://lists.ovirt.org/mailman/listinfo/devel [12] http://ovirt-infra-docs.readthedocs.org/en/latest/ [13] http://www.ovirt.org/develop/infra/infrastructure-documentation/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

ovirt 3.5 to 3.6 upgrade
by Paul Dyer 30 Mar '16

30 Mar '16

Hi, after upgrade to ovirt 3.6, the ovirt-release35 repo remains on the manager machine (non-hosted engine). There is also a list of rpms from the 3.5 repo. Should the 3.5 repo be removed? What about the rpms from the 3.5 repo? Should they stay or go? Here is a list of 3.5 repo rpms still installed: # yum list installed |grep ovirt-3.5 ovirt-engine-jboss-as.x86_64 7.1.1-1.el6 @ovirt-3.5 patternfly1.noarch 1.3.0-1.el6 @ovirt-3.5-patternfly1-noarch-epel python-daemon.noarch 1.5.2-1.el6 @ovirt-3.5-epel python-kitchen.noarch 1.1.1-1.el6 @ovirt-3.5-epel python-lockfile.noarch 0.8-3.el6 @ovirt-3.5-epel python-ply.noarch 3.4-4.el6 @ovirt-3.5-epel python-websockify.noarch 0.6.0-3.el6 @ovirt-3.5-epel xalan-j2.noarch 2.7.1-8.jbossorg_1.jpp6 @ovirt-3.5-jpackage-6.0-generic Thanks, Paul -- Paul Dyer, Mercury Consulting Group, RHCE 504-302-8750

2 1

[vdsm] new internal stable modules + proposal
by Francesco Romani 30 Mar '16

30 Mar '16

Hi, in the last Vdsm developer call we agreed to promote a few modules in the common repository. The common repository provides the additional guarantees over regular modules in lib/vdsm/ - stable API - (thus) safe to use across verticals the planned moves are: lib/vdsm/schedule.py -> lib/vdsm/common/schedule.py lib/vdsm/periodic.py -> lib/vdsm/common/periodic.py lib/vdsm/virt/api.py -> lib/vdsm/common/api.py Question is if those modules should go under common/ or under another subdirectory, maybe infra? Lastly, i have a proposal about better handling of those modules. First, the mere fact a module is placed under lib/vdsm/common provides the extra guarantees I mentioned. But should we added more annotations? for example something like __API__ = {} near the top of the module if this attribute exist, then the module is safe to use across verticals, has stable API and so forth (this is _in addition_ to the common/ package, not as replacement). Like: __API__ = { "introduced-in": "4.14.0", "deprecated-from": "4.18.0", "removed-at": "4.20.0", "contact": "fromani(a)redhat.com" } We could refine further this concept if we like it. The idea is to be lightweight as possible while carrying all the information we need. Comments welcome as usual bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani

3 7