Description of problem: When importing a subscription manifest that contains a large number of products/subscriptions, if the import process takes longer than 120 seconds (hammer's default timeout), the process fails. Version-Release number of selected component (if applicable): How reproducible: ~50% Steps to Reproduce: 1. Install Satellite 6.2 Beta (or 6.1, it doesn't matter) 2. Import a subscription manifest with a large number of products via hammer. Example: time hammer -d subscription upload --file /root/manifest.zip --organization "Default Organization" 3. Actual results: If the manifest import takes > 120 seconds, it fails. Expected results: Manifest import should succeed. Additional info: This issue is more pronounced on virtual machines that are on overcommitted hypervisors or systems that are at or around the minimal system requirements for Satellite (https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.1/html-single/Installation_Guide/index.html#sect-Red_Hat_Satellite-Installation_Guide-Prerequisites)
On my test system (a VM with 4vCPU & 16GB of RAM, running as the sole VM on a hypervisor with 4 CPUs and 32GB of RAM), I can successfully reproduce this issue with 100% success with my manifest. Manifest import time is seemingly a product of the resources of the system (and/or if it is on an overcommitted hypervisor) AND the diversity of the products in its manifest. And since neither of those are variables that we (or the Satellite user) control, identifying if/when the user will hit this issue is difficult. Possible ways to solve/mitigate this include: * Change the default timeout in hammer to infinite (-1). * Tell the user (in the Hammer CLI guide) to set the timeout to infinite * breaking the manifest import into smaller 'chunks' which have a high probability of completing in the default timeout (again, 120 seconds)
*** This bug has been marked as a duplicate of bug 1334996 ***