Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1119411

Summary:	[RFE] spacewalk-clone-by-date reporting feature to list updates without actually creating channel
Product:	[Community] Spacewalk	Reporter:	Stephen Herr <sherr>
Component:	Clients	Assignee:	Stephen Herr <sherr>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.2	CC:	cperry, dyordano, jscalf, mmraka, rjerrido, satqe-list, xdmoon
Target Milestone:	---	Keywords:	FutureFeature, Patch
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	spacewalk-utils-2.3.1-1	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:	1014755	Environment:
Last Closed:	2015-04-14 19:04:10 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:
Embargoed:
Bug Depends On:
Bug Blocks:	1207293

Description Stephen Herr 2014-07-14 17:32:02 UTC

+++ This bug was initially created as a clone of Bug #1014755 +++

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

The request is for the ability to list or report the updates that would be included in a clone channel created using spacewalk-clone-by-date without also creating the channel. 

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

The customer has a lengthy quality assurance process. They have to run all system updates past their internal change management team. They use spacewalk-clone-by-date to create channels containing security updates as part of their regular system updates. Having a way to list all of the changes that would go into the cloned channel would enable them to quickly report to their change management team what updates need to be applied. It would also cut down on the number of child channels that are created.

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

They would like an option along the lines of the "yum list updates" command, for example:
# spacewalk-clone-by-date <options> --list-updates

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

They would run:
# spacewalk-clone-by-date <options> --list-updates

And posted to the standard output would be the list of packages that would be updated in the cloned channel.

--- Additional comment from Clifford Perry on 2013-10-03 11:52:28 EDT ---

maybe call it --dry-run  and it exits somewhere, saving stuff to log file.

--- Additional comment from Jennifer Scalf on 2013-10-03 13:49:18 EDT ---

(In reply to Clifford Perry from comment #1)
> maybe call it --dry-run  and it exits somewhere, saving stuff to log file.

That works. The name is not important to the customer, just the functionality. And --dry-run describes the behavior better than --list-updates. Thanks.

Comment 1 Stephen Herr 2014-07-14 18:21:24 UTC

As described this should probably be closed as won't fix.

The ability to see what errata would be applied to a non-existent channel is not possible without a compete rewrite of the clone-by-date tool, and the ability to see what *packages* will be cloned into the channel is not possible without rewriting the Spacewalk API *and* the clone-by-date tool.

However, we can provide something that will hopefully be useful. There is now a --dry-run option that can be specified on the command line or in a config file that:
1) looks for the channel specified, if it does not exist will create one with original packages (no errata cloned).
2) see what *errata* would be cloned given the current options, write them to a log file, and exit without changing anything.

Hopefully this should make the QA process easier. Instead of creating new cloned channels just so see what the differences between that channel and existing one are, now they should be able to do a --dry-run against the existing channel and see what (if any) errata would be cloned that are not already there.

Committing to Spacewalk master:
e0ed72bdf2caf8d6856946e56dd6b70058396370
35aa2a05313b189f4c408aec95b5f62e758ade7d

Comment 2 Grant Gainey 2015-03-23 16:59:36 UTC

Moving bugs to ON_QA as we move to release Spacewalk 2.3

Comment 3 Grant Gainey 2015-04-14 19:04:10 UTC

Spacewalk 2.3 has been released. See

https://fedorahosted.org/spacewalk/wiki/ReleaseNotes23