Bug 1718168

Summary:	[RFE] Repackage ovirt-imageio as a single package for 2.0
Product:	[oVirt] ovirt-imageio	Reporter:	Sandro Bonazzola <sbonazzo>
Component:	RFEs	Assignee:	Nir Soffer <nsoffer>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ilan Zuckerman <izuckerm>
Severity:	medium	Docs Contact:
Priority:	urgent
Version:	2.0.0	CC:	aefrat, bugs, derez, lsvaty, nsoffer, royoung, tnisan
Target Milestone:	ovirt-4.4.1	Keywords:	DevelBlocker, Improvement
Target Release:	---	Flags:	sbonazzo: ovirt-4.4? sbonazzo: planning_ack? sbonazzo: devel_ack? sbonazzo: testing_ack?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-06-03 06:20:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1701464

Description Sandro Bonazzola 2019-06-07 07:16:18 UTC

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.

Comment 1 Sandro Bonazzola 2019-06-07 07:19:30 UTC

Please note that ovirt-imageio is used also by ovirt-engine so it must be built for RHEL7 too with python2.

Comment 2 Sandro Bonazzola 2019-10-07 11:01:02 UTC

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.

Comment 3 Nir Soffer 2020-01-14 22:06:27 UTC

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.

Comment 4 Nir Soffer 2020-04-26 00:44:01 UTC

Finished since ovirt-imageio 2.0.2.

Comment 5 Ilan Zuckerman 2020-06-01 11:36:02 UTC

Nir, Please provide verification steps.

Comment 7 Nir Soffer 2020-06-02 17:03:36 UTC

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.

Comment 8 Avihai 2020-06-03 06:20:24 UTC

(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,