On Fri, Jan 29, 2016 at 12:17 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
lucas castro <lucascastroborges@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel