According to Nir's comment on https://gerrit.ovirt.org/#/c/100314/ we want to overall packaging. The current way we package imageio is not maintainable. We will have single package named python3-ovirt-imageio, installing single python package (ovirt_imageio). This is our chance to get rid of the crazy 3 builds we have today, and the external dependencies we have in vdsm (on ovirt-imageio-daemon and ovirt-imageio-common). I think we will also bump the version to 2.0, since the packages are not compatible. Since we need to handle the packaging for python3 support and RHEL 8 support, it doesn't make sense to spend time on the packaging with current 3 package architecture if this change is already planned.
Please note that ovirt-imageio is used also by ovirt-engine so it must be built for RHEL7 too with python2.
I see in bug #1701522 that this won't be handled in 4.4, can you please re-target this one? Dropping current target on 4.4 to be re-evaluated.
Today we have single git repo with 3 separate python projects, each with its own build system (spec, setup.py, version.py, makefile, tox.ini, conftest.py, etc). Finally we have 3 repos in brew, and we need to do 4 builds for every release. We want to move to: - single spec file - single version - single makefile - single build in brew - single conftest.py - single tox.ini - minimum number of rpms Once we unify the daemon and proxy we can move to one ovirt-imageio package. We may split client code to ovirt-imageio-client package. This package can require qemu-nbd and qemu-img, but it must depend on ovirt-imageio since the client is using the same infrastructure as the daemon (nbd backend http backend). Both packages must be build from the same source tarball (like vdsm). Open issues: - vdsm is importing the directio module from ovirt-imageio-daemon to the kvm2ovirt tool. Should be fixed by using imageio upload instead of importing modules from imageio.
Finished since ovirt-imageio 2.0.2.
Nir, Please provide verification steps.
The bug is poorly specified. The packaging changes are about the project structure and the way it was built in brew. The user experience (having multiple rpm packages) is correct. I suggest to close this as CURRENTRELEASE since there is nothing interesting to verify.
(In reply to Nir Soffer from comment #7) > The bug is poorly specified. The packaging changes are about > the project structure and the way it was built in brew. The user > experience (having multiple rpm packages) is correct. > > I suggest to close this as CURRENTRELEASE since there is nothing > interesting to verify. I agree, closing,