+++ 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.
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
Moving bugs to ON_QA as we move to release Spacewalk 2.3
Spacewalk 2.3 has been released. See https://fedorahosted.org/spacewalk/wiki/ReleaseNotes23