Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
User scenario: "hammer repository upload-content --path /mnt/of/slow/device" starts to upload packages to a repo, but randomly fails with error:
Failed to upload file 'kernel-debuginfo-4.2.0-300.ec2.x86_64.rpm' to repository. Please check the file and try again.
The reason is, hammer_cli_katello/repository.rb uses for each such RPM upload:
def import_upload_ids(ids)
params = {:id => get_identifier,
:upload_ids => ids
}
resource.call(:import_uploads, params)
end
The "resource.call" can timeout on hammer timeout. That timeout event is silently ignored and next RPM is attempted to be uploaded. So new foreman task is kicked while previous one is still running - while it has acquired relevant locks. So the new task fails with "Required lock is already taken by other running tasks." error and hammer just logs "Failed to upload file" error.
That is confusing for a user. Please either ignore the timeout on this call, or preferably at least print the timeout event so the user knows something wrong happened.
Version-Release number of selected component (if applicable):
tfm-rubygem-hammer_cli_katello-0.0.22.26-1.el7sat.noarch
Sat6.2.4
How reproducible:
100%
Steps to Reproduce:
1. To mimic slow package upload, artificially decrease hammer timeout by setting to /etc/hammer/cli.modules.d/foreman.yml ":request_timeout: 5"
2. Get some packages of few hundreds of MBs size (I used kernel-debuginfo) and put them to a directory (/tmp/many_rpms/ is used below)
3. Call in hammer shell:
product create --name=custom_product_with_many_repos --organization-id=1 --label=custom_product_with_many_repos
repository create --content-type=yum --download-policy=immediate --label=custom_repo_many_rpms --name=custom_repo_many_rpms --organization-id=1 --product=custom_product_with_many_repos
repository upload-content --path /tmp/many_rpms/ --product custom_product_with_many_repos --organization-id=1 --name custom_repo_many_rpms
Actual results:
Sporadic to frequent errors:
Failed to upload file 'kernel-debuginfo-4.2.0-300.ec2.x86_64.rpm' to repository. Please check the file and try again.
Expected results:
No such error, or at least preceded by timeout warning.
Additional info:
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.
Description of problem: User scenario: "hammer repository upload-content --path /mnt/of/slow/device" starts to upload packages to a repo, but randomly fails with error: Failed to upload file 'kernel-debuginfo-4.2.0-300.ec2.x86_64.rpm' to repository. Please check the file and try again. The reason is, hammer_cli_katello/repository.rb uses for each such RPM upload: def import_upload_ids(ids) params = {:id => get_identifier, :upload_ids => ids } resource.call(:import_uploads, params) end The "resource.call" can timeout on hammer timeout. That timeout event is silently ignored and next RPM is attempted to be uploaded. So new foreman task is kicked while previous one is still running - while it has acquired relevant locks. So the new task fails with "Required lock is already taken by other running tasks." error and hammer just logs "Failed to upload file" error. That is confusing for a user. Please either ignore the timeout on this call, or preferably at least print the timeout event so the user knows something wrong happened. Version-Release number of selected component (if applicable): tfm-rubygem-hammer_cli_katello-0.0.22.26-1.el7sat.noarch Sat6.2.4 How reproducible: 100% Steps to Reproduce: 1. To mimic slow package upload, artificially decrease hammer timeout by setting to /etc/hammer/cli.modules.d/foreman.yml ":request_timeout: 5" 2. Get some packages of few hundreds of MBs size (I used kernel-debuginfo) and put them to a directory (/tmp/many_rpms/ is used below) 3. Call in hammer shell: product create --name=custom_product_with_many_repos --organization-id=1 --label=custom_product_with_many_repos repository create --content-type=yum --download-policy=immediate --label=custom_repo_many_rpms --name=custom_repo_many_rpms --organization-id=1 --product=custom_product_with_many_repos repository upload-content --path /tmp/many_rpms/ --product custom_product_with_many_repos --organization-id=1 --name custom_repo_many_rpms Actual results: Sporadic to frequent errors: Failed to upload file 'kernel-debuginfo-4.2.0-300.ec2.x86_64.rpm' to repository. Please check the file and try again. Expected results: No such error, or at least preceded by timeout warning. Additional info: