Bug 1382716

Summary:	RFE: split to multiple packages
Product:	Red Hat Enterprise Linux 7	Reporter:	Jaroslav Škarvada <jskarvad>
Component:	tuned	Assignee:	Jaroslav Škarvada <jskarvad>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-daemons
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	jeder, jskarvad, mkolaja, olysonek, tcerna, thozza
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-01-08 10:20:31 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	1400961

Description Jaroslav Škarvada 2016-10-07 13:37:36 UTC

Description of problem:
Currently Tuned is packaged in multiple subpackages which is not flexible as it currently supports various products through various channels and this number may increase. Simple update in subpackage targeted to specific product (e.g. NFV) requires main package (and all subpackages) to be rebuilt and updated in specific channels. This is hard to synchronize as each product can have different release cycle.

The proposal is to split Tuned both upstream and downstream to multiple packages and tight them together through API version. In such case the profiles could be updated separately. This should be easy to achieve upstream - there is currently API. In downstream (Fedora/RHEL) it will require addition of several new standalone packages (i.e. new package process, review, etc.).

Tuned upstream is currently moving to new home and switching to new infrastructure, so it could be handled altogether.

Version-Release number of selected component (if applicable):
tuned-2.7.1-3.el7

Or upstream tuned-2.7.1

How reproducible:
Always

Steps to Reproduce:
1. Check the tuned spec file

Actual results:
One package/spec and multiple subpackages

Expected results:
Multiple speca/packages

Additional info:
There is also proposal to split base profiles from Tuned engine. Currently I am not sure about the benefits:

Pros:
- base profiles could be updated without the engine update
- users using only custom profiles wouldn't need to install base profiles

Cons:
- many past updates of base profiles required also  API update (i.e. required engine update)
- engine and base profiles needs to be in the base channel, throughput-performance profile is usually auto-enabled, i.e. both packages will have to be installed by default
- Tuned without the base profiles is quite unusable (in case you you have no 3rd profiles)

Comment 1 Jaroslav Škarvada 2016-10-07 14:06:07 UTC

(In reply to Jaroslav Škarvada from comment #0)
> Description of problem:
> Currently Tuned is packaged in multiple subpackages which is not flexible as
> it currently supports various products through various channels and this
> number may increase. Simple update in subpackage targeted to specific
> product (e.g. NFV) requires main package (and all subpackages) to be rebuilt
> and updated in specific channels. This is hard to synchronize as each
> product can have different release cycle.
> 
> The proposal is to split Tuned both upstream and downstream to multiple
> packages and tight them together through API version. In such case the
> profiles could be updated separately. This should be easy to achieve
> upstream - there is currently API. In downstream (Fedora/RHEL) it will
> require addition of several new standalone packages (i.e. new package
> process, review, etc.).
> 
This proposal is for RHEL-7 (i.e. RHEL-7.4+).

> There is also proposal to split base profiles from Tuned engine. Currently I
> am not sure about the benefits:
>
I think if we choose to go this way it's more for RHEL-8, not to pollute stable release with virtual Provides/Requires/Obsoletes.

Comment 3 Jaroslav Škarvada 2017-01-04 13:20:25 UTC

For RHEL-7 I think it makes sense to loose profile dependencies (which will allow products to more easy combine Tuned/Tuned profiles packages/subpackages) and to split only subpackages which are/were causing problems (e.g. nfv, cpu-partitioning, ...). 

I think that global split of all profiles subpackages is not suitable for RHEL-7 and would present more maintainer overhead (e.g. for rebases). I think the global split is something which could wait for RHEL-8.

Comment 5 Red Hat Bugzilla Rules Engine 2019-01-08 10:20:31 UTC

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.