Bug 677296

Summary:	[RFE] yum update needs a cut-off date
Product:	Red Hat Enterprise Linux 5	Reporter:	J.H.M. Dassen (Ray) <rdassen>
Component:	yum	Assignee:	James Antill <james.antill>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	low	Docs Contact:
Priority:	low
Version:	5.6	CC:	asv, fweimer, mkhusid, rbinkhor
Target Milestone:	rc	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-11 20:05:34 UTC	Type:	---
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:	554476

Description J.H.M. Dassen (Ray) 2011-02-14 09:47:56 UTC

2. What is the nature and description of the request?

Customer would like to have a cut off date feature with yum where they are
looking for to skip packages from the repositories with dates after the
specified cutoff so that they can apply updates in a more controlled manner.

3. Why does the customer need this? (List the business requirements here)

In an environment with many sets of "development/quality assurance/production"
servers, it is important to have a simple mechanism for applying updates to
dev, then later to qa then later to production. While clones of the satellite
distribution channels can be made, this creates extra work and causes it's own
short-comings. By providing a mechanism within yum itself, each department or
group responsible for maintaining these different servers can easily set their
own schedules of when updates get applied, while still providing the
transparency of what updates are available. Providing this feature from yum
itself simplifies the scheduling and application of a centralized repo without
the need for creating clones channels.

4. How would the customer like to achieve this? (List the functional
requirements here)

Customer would like to control feature on updates provided by yum by
introducing a cut off date feature. A new option on yum like --cutoff-date
yyyy-mm-dd would cause yum to skip files from the repos with dates after the
specified cutoff. 

5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

Once implemented, we can test the feature of yum by specifying cut off dates
and skip the packages and apply it in a more controlled manner.

6. Is there already an existing RFE upstream or in Red Hat bugzilla?

No

7. How quickly does this need resolved? (desired target release)

Minor release

8. Does this request meet the RHEL Inclusion criteria (please review)

Yes
   
9. List the affected packages

yum

Comment 2 James Antill 2011-02-14 16:06:03 UTC

> Customer would like to have a cut off date feature with yum where they are
> looking for to skip packages from the repositories with dates after the
> specified cutoff so that they can apply updates in a more controlled manner.

 The problem is that the information they want is:

    What is the date that a package was added to a repo.

...and yum doesn't have that. We have builddate, but that is not the same.

> 3. Why does the customer need this? (List the business requirements here)

> In an environment with many sets of "development/quality assurance/production"
> servers, it is important to have a simple mechanism for applying updates to
> dev, then later to qa then later to production.

 Right, so what they really want isn't this date thing IMO.
 In RHEL-6.1 yum will have this ability:

Machine 1:

   yum update

[yum spits out a file like yum_save_tx-2011-02-07-11-44eQMtZk.yumtx in $TMPDIR]

Machine 2:

[much time later]

   yum load-ts yum_save_tx-2011-02-07-11-44eQMtZk.yumtx

...which will be the same transaction that happened on "machine 1", even if there are newer versions of packages.

 I have a RHEL-5 repo. which has a build from rawhide in it (on repos.fedorapeople.org) ... so they can see what this works like. This feature is unlikely to get backported to RHEL-5 though.

Comment 3 J.H.M. Dassen (Ray) 2011-02-14 16:40:45 UTC

(In reply to comment #2)
>  Right, so what they really want isn't this date thing IMO.
>  In RHEL-6.1 yum will have this ability:

This sounds like a very reasonable approach to handling this requirement
which I suspect is a common one for environments using DTAP
<http://en.wikipedia.org/wiki/Development,_testing,_acceptance_and_production> workflows. 

Abhilash, you own the communication with the customer behind this request -
can you please check with them whether the ability that James describes in
comment #2 meets their needs?

Comment 4 seth vidal 2011-02-14 17:59:09 UTC

I just sent a patch upstream to store the yum transaction save file in the add on history store so you can retrieve the transaction file from any transaction in the historydb.

Comment 10 Mike Khusid 2011-08-11 20:03:21 UTC

This enhancement request was evaluated by Red Hat Product Management for inclusion a Red Hat Enterprise Linux maintenance release.

Red Hat does not currently plan to provide this enhanced functionality in a Red Hat Enterprise Linux update for currently deployed products.

With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.

For more information on Red Hat Enterprise Linux maintenance policies, please consult: https://access.redhat.com/support/policy/updates/errata/

Red Hat values your feedback and will take this enhancement request into consideration for future major releases of Red Hat Enterprise Linux.

Comment 11 RHEL Program Management 2011-08-11 20:05:34 UTC

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