Bug 1153792

Summary: spacewalk-clone-by-date will not clone updated errata
Product: Red Hat Satellite 5 Reporter: Dave <dave.kalaluhi>
Component: ServerAssignee: Jan Dobes <jdobes>
Status: CLOSED DUPLICATE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 560CC: sferguso, tlestach, xdmoon
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-18 15:12:28 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: 924189    

Description Dave 2014-10-16 19:01:14 UTC 
Description of problem: spacewalk-clone-by-date is not correctly cloning errata that has been UPDATED into our downstream channels.

When issuing the command:
[root@*****]$ spacewalk-clone-by-date --config=someconfigfile.config -d \ 2014-09-30 

it is skipping the bash errata that was updated on 30-Sep-2014.

Doing some more testing, I realized that if I change the to-date to 16-Oct it will clone everything that has been released, but NOT the bash errata.


Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce: Using spacewalk-clone-by-date
1. clone RH channel to 2014-09-26 (this will clone the initial bash errata released on that day)
2. clone RH channel to 2014-09-30
3. Check private channels

Actual results:
The bash errata is still the previous 09/26/2014 


Expected results:
The updated errata, released on the 30th would be cloned to private channels


Additional info:

It appears that spacewalk-clone-by-date is checking the issue date of the errata, and NOT the updated date.

In the case of RHSA-2014:1306, which was originally issued on 09/26 and updated on 09/30, it was seeing the errata in the channel and skipping it, not cloning the update. Before and after the clone, both the issue date and the updated date were 09/26
Comment 3 Tomas Lestach 2016-08-18 15:12:28 UTC 
I feel this already has been resolved by Bug 905259.
Closing as duplicate.

*** This bug has been marked as a duplicate of bug 905259 ***