On Fri, Jan 29, 2016 at 12:17 PM, Milan Zamazal <[email protected]> wrote: > lucas castro <[email protected]> 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
