Bug 1119411 - [RFE] spacewalk-clone-by-date reporting feature to list updates without actually creating channel
Summary: [RFE] spacewalk-clone-by-date reporting feature to list updates without actua...
Alias: None
Product: Spacewalk
Classification: Community
Component: Clients
Version: 2.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Stephen Herr
QA Contact: Red Hat Satellite QA List
Depends On:
Blocks: space23
TreeView+ depends on / blocked
Reported: 2014-07-14 17:32 UTC by Stephen Herr
Modified: 2015-04-14 19:04 UTC (History)
7 users (show)

Fixed In Version: spacewalk-utils-2.3.1-1
Doc Type: Enhancement
Doc Text:
Clone Of: 1014755
Last Closed: 2015-04-14 19:04:10 UTC

Attachments (Terms of Use)

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:

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


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