Bug 1382716 - RFE: split to multiple packages
Summary: RFE: split to multiple packages
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tuned
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jaroslav Škarvada
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1400961
TreeView+ depends on / blocked
 
Reported: 2016-10-07 13:37 UTC by Jaroslav Škarvada
Modified: 2019-01-08 10:20 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-08 10:20:31 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.