Progress report on Vdsm Debian packaging
by Milan Zamazal
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.
7 years, 11 months
Vdsm api package
by Nir Soffer
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
8 years
Maintenance Notification: *.ovirt.org Services Today at 18:00 IST (17:00 CET)
by Anton Marchukov
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
8 years
are there any ways to disable the log file?
by zhukaijie
"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.
8 years
[ANN] oVirt 3.6.5 First Release Candidate is now available for testing
by Sandro Bonazzola
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
8 years
Re: [ovirt-devel] virt-v2v become zombie via python cpopen on error
by Michal Skrivanek
> 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
8 years
oVirt Node Next builds are currently broken
by Fabian Deutsch
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
8 years
Get Involved with oVirt project! Spring edition
by Sandro Bonazzola
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-f...
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%3Aovir...
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-co...
[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
8 years
ovirt 3.5 to 3.6 upgrade
by Paul Dyer
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
8 years
[vdsm] new internal stable modules + proposal
by Francesco Romani
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
8 years
