Description of problem: Command issued = hammer capsule content synchronize --id 4 Output = [root@sat6host ~]# hammer capsule content synchronize --id 4 [Foreman] Password for satadmin: Could not synchronize capsule content: Error: Request Timeout Version-Release number of selected component (if applicable): How reproducible: Every time in this environment Steps to Reproduce: 1. have a bunch of unsynchronized content 2. execute hammer capsule content synchronize --id 4 via command line 3. Actual results: Could not synchronize capsule content: Error: Request Timeout Expected results: Successful job message or progress indicator in the command line. Perhaps a confirmation that a sync job started. Additional info:
To accomplish this, we'd need to move all of the repository creation and updating to the run phase rather than the planning phase. I think there are a lot of good benefits to this. Wouldn't be a trivial change though.
Justin, would the fix in the bug below resolve the issues described in this report? https://bugzilla.redhat.com/show_bug.cgi?id=1405134
That bz would help in that long task spawning would be able to be handled, but the real problem IMHO is that initiating a capsule sync tasks grows linearly with the # of capsules and # of repos to sync. I think that should be fixed here.
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.