9:15 a.m.
On Fri, Jan 29, 2016 at 12:17 PM, Milan Zamazal <mzamazal(a)redhat.com> wrote:
lucas castro <lucascastroborges(a)gmail.com> writes:
> Who is working on ovirt debian porting,
I'm working on inclusion of Vdsm into Debian. ovirt-guest-agent is
already included in Debian (packaged by another Debian maintainer). I'm
not aware about any plans to package Engine for Debian nor I plan to do
so.
There are also Vdsm Debian packages provided by oVirt at
http://resources.ovirt.org/pub/ovirt-3.6/debian/, but I don't recommend
using them if you are going to use packages from standard Debian
distribution once they are ready. While the packages to be included in
Debian started from those provided by oVirt, there are many fixes in
them and upgrading from oVirt repository packages to packages from
Debian is not supported (may change if there is strong demand for that).
So mixing those is likely to cause troubles.
As for Vdsm in Debian, I've already uploaded most of the supporting
packages (Python libraries, MoM) to Debian unstable. Vdsm itself is in
preparation.
One blocker is old version of sanlock package in Debian and missing
sanlock-python package. I wrote to the Debian package maintainer a few
days ago, no response so far. In the meantime, it's possible to use
sanlock packages by oVirt from the URL mentioned above. (Please note I
can't simply upload Debian package of another maintainer without his
consent, so we must be patient.)
> And how can I help ?
If you'd like to help with Vdsm packaging in Debian, you can do so in
any of the following ways:
- Providing input on your needs.
- Providing feedback on what to do with /rhev/data-center mounts
directory in Vdsm. It's FHS incompatible and must be changed for
Debian (the current location in the package is
/run/vdsm/rhev/data-center).
I would not keep "rehv" in the new path, we certainly will remove it
when we can,
even on rhel.
We started to use /run/vdsm/storage for images directories about 2 years ago.
I think the plan was to move /rhev/data-center contents there, but it broke
backward compatibility, so we have partial solution, keeping domains and images
directories in /run/vdsm/domain/image, and symbolic links to logical volumes
for these images, when the logical volumes are activated.
It looks like no code is using the links in /run/vdsm/storage, so this may be
good place to move rhev/data-center contents in the future.
I suggest to keep /rhev/data-center as is for now, to make it easier to support
vdsm on debain.
If you must avoid /rhev/data-center, move it to /run/vdsm/data-center, but note
that future version of vdsm may move it to /run/vdsm/storage, or
another location,
so old debain code will not be compatible with new debian code :-)
It would be easier to support vdsm if the runtime configuration is the same on
all platforms.
The unpleasant thing is that AFAIK
migrations are not possible with current Vdsm across machines with
mounts at different locations, so we should be careful.
- Testing vdsm* packages once they are ready. They're not yet but once
they are, testing them will be very welcome.
- Providing feedback on the packaging. The git repository is on Alioth:
https://anonscm.debian.org/cgit/collab-maint/vdsm.git/ . BTW, if
anybody needs commit access (and doesn't have it) to the repository,
tell me. Just please coordinate with me in any case so that we avoid
duplicate work or conflicting plans.
- The `vdsm*' packages are currently lintian clean, but completely
untested, even installation may not work. If you'd like to check the
installation and to fix contingent bugs preventing it, it's welcome.
You'll also need safelease
(https://anonscm.debian.org/cgit/collab-maint/safelease.git/), not yet
in Debian but ready to upload, I'll do so soon.
- Testing whether all the Vdsm related packages from unstable
(python-cpopen, python-threading, ioprocess, safelease, mom, vdsm*)
work on Debian 8 (jessie) as well. Ideally, they might work
unchanged, but in case they don't we may be considering backporting
them.
- You can also review patches in debian/patches. Maybe some of the
changes should be incorporated upstream, maybe some of them should be
improved.
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel