Description of problem: Having a Capsule in Library Lifecycle Environment, it should get synchronized all content from Satellite. But when I upload a package to a custom repo in a custom product, the change is published on Satellite noly and nothing is propagated to the Capsule. (same applies after uploading a package to RH repo, but I dont assume a customer will manually change content of RH repo) Version-Release number of selected component (if applicable): Sat 6.2.12 How reproducible: 100% Steps to Reproduce: 1. Have a Capsule, fully synced. 2. Create a product, a repo and upload a package there: hammer -u admin -p redhat product create --name myproduct --organization-id=1 hammer -u admin -p redhat repository create --name myrepo --product=myproduct --organization-id=1 --content-type=yum hammer -u admin -p redhat repository upload-content --name=myrepo --organization-id=1 --product=myproduct --path /path/to/some/repo.rpm 3. Ensure all tasks completed (more precisely: no capsule sync task is in progress). 4. Check if the repository has that package - run both on Sat and Caps: ls /var/lib/pulp/published/yum/master/yum_distributor/*-myproduct-myrepo/*/ (in above command, 1st '*' is expanded to Organization and 2nd to timestamp since Epoch - both shall be unique) 5. Synchronize the Caps: hammer -u admin -p redhat capsule content synchronize --id 2 --organization-id 1 6. Check if the repo has that package also on Caps: ls /var/lib/pulp/published/yum/master/yum_distributor/*-myproduct-myrepo/*/ Actual results: 4. shows a package and metadata exists only on Satellite. Capsule does not have that repo at all. 6. shows the repo properly created&published also to Capsule. Expected results: The repo is properly created&synced&published even in step 4. Additional info:
The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Rich Jerrido or Bryan Kearney or your account team. If we do not hear from you, we will close this bug out. Thank you.
(In reply to Bryan Kearney from comment #3) > The Satellite Team is attempting to provide an accurate backlog of bugzilla > requests which we feel will be resolved in the next few releases. We do not > believe this bugzilla will meet that criteria, and have plans to close it > out in 1 month. This is not a reflection on the validity of the request, but > a reflection of the many priorities for the product. If you have any > concerns about this, feel free to contact Rich Jerrido or Bryan Kearney or > your account team. If we do not hear from you, we will close this bug out. > Thank you. I think this requires a simple amend of one task (similarly like CV promote/publish has - to trigger Capsule sync for some repo(s) afterwards). While not having this implemented, it is a valid Satellite bug where a redundant manual work is required to trigger the Caps sync is required - that can break some automated processes / pipelines. Please give me 1-2 months and I will try come up with a patch.
Here is the patch for 6.4.1: --- /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.42/app/lib/actions/katello/repository/upload_files.rb.orig 2018-12-31 12:17:40.841122769 +0100 +++ /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.42/app/lib/actions/katello/repository/upload_files.rb 2018-12-31 13:23:20.575255011 +0100 @@ -5,6 +5,8 @@ module Actions module Katello module Repository class UploadFiles < Actions::EntryAction + middleware.use Actions::Middleware::KeepCurrentUser + def plan(repository, files) action_subject(repository) tmp_files = prepare_tmp_files(files) @@ -35,6 +37,11 @@ module Actions delete_tmp_files(tmp_files) if $ERROR_INFO && tmp_files end + def run + ForemanTasks.async_task(Repository::CapsuleSync, ::Katello::Repository.find(input[:repository][:id])) + rescue ::Katello::Errors::CapsuleCannotBeReached # skip any capsules that cannot be connected to + end + def humanized_name _("Upload into") end
Upstream issue and PR created with the simple patch; patch itself successfully tested on 6.4.1.
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25761 has been resolved.
*** Bug 1621038 has been marked as a duplicate of this bug. ***
Mike, could you pls. consider backporting this to 6.5 and 6.4.z (not sure if also to 6.3.z) based on the previous (private) comment? Codefix https://github.com/Katello/katello/pull/7906/files is easy to backport, on 6.4 it requires 2 more lines, see below patch from my 6.4.1: # diff /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.42/app/lib/actions/katello/repository/upload_files.rb.orig /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.42/app/lib/actions/katello/repository/upload_files.rb -rup --- /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.42/app/lib/actions/katello/repository/upload_files.rb.orig 2018-12-31 12:17:40.841122769 +0100 +++ /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.42/app/lib/actions/katello/repository/upload_files.rb 2018-12-31 13:23:20.575255011 +0100 @@ -5,6 +5,8 @@ module Actions module Katello module Repository class UploadFiles < Actions::EntryAction + middleware.use Actions::Middleware::KeepCurrentUser + def plan(repository, files) action_subject(repository) tmp_files = prepare_tmp_files(files) @@ -35,6 +37,11 @@ module Actions delete_tmp_files(tmp_files) if $ERROR_INFO && tmp_files end + def run + ForemanTasks.async_task(Repository::CapsuleSync, ::Katello::Repository.find(input[:repository][:id])) + rescue ::Katello::Errors::CapsuleCannotBeReached # skip any capsules that cannot be connected to + end + def humanized_name _("Upload into") end
Steps to reproduce: 1. Setup capsule and have it fully synced. 2. Create a custom repo (I used ttps://partha.fedorapeople.org/test-repos/rpm-with-productid/elephant-0.3-0.8.noarch.rpm) 3. Ensure all tasks completed (more precisely: no capsule sync task is in progress). 4. Check if the repository has that package - run both on Sat and Caps: ls /var/lib/pulp/published/yum/master/yum_distributor/*-myproduct-myrepo/*/ 5. Synchronize the Capsule via Infrastructure -> capsule -> <capsule name> -> synchronized -> complete sync 6. Check if the repo has that package also on Caps: ls /var/lib/pulp/published/yum/master/yum_distributor/*-myproduct-myrepo/*/ Expected: Satellite: -rw-r--r--. 1 apache apache 92 Apr 22 11:28 1e25fab79758b4d8ffef13a9dfdca116f1c43c29b29b8ee794989bb27d45ec87-updateinfo.xml.gz -rw-r--r--. 1 apache apache 263 Apr 22 11:28 74db048e56b7cb389cf882b7facea66931588bd220d48f5f6390e937763f0d57-filelists.xml.gz -rw-r--r--. 1 apache apache 244 Apr 22 11:28 87815fc3b9e0ba0a41a6be2c4afb7c1175e1bdf440720de9d418158ae63f8821-other.xml.gz -rw-r--r--. 1 apache apache 124 Apr 22 11:28 a27718cc28ec6d71432e0ef3e6da544b7f9d93f6bb7d0a55aacd592d03144b70-comps.xml -rw-r--r--. 1 apache apache 649 Apr 22 11:28 ac61469eefcac0b9e9fdec558c95ec71245c669ce68031910ca826d12bdb8af5-primary.xml.gz -rw-r--r--. 1 apache apache 2143 Apr 22 11:28 repomd.xml Capsule: -rw-r--r--. 1 apache apache 92 Apr 22 11:28 2aad2c89e394c213631bca0f8f3b4b64ae3ac81c41411333c2fe83d5665d0b8c-updateinfo.xml.gz -rw-r--r--. 1 apache apache 244 Apr 22 11:28 9a4b0e2b8b8c97e4c6ace8d9c027af8aba2a96a9837970f4d0e04a32ce372dba-other.xml.gz -rw-r--r--. 1 apache apache 124 Apr 22 11:28 a27718cc28ec6d71432e0ef3e6da544b7f9d93f6bb7d0a55aacd592d03144b70-comps.xml -rw-r--r--. 1 apache apache 649 Apr 22 11:28 b370f730a9b749b1b1495416711d30c96a3aa6e78ea0b2e6c1db9c27a48f707d-primary.xml.gz -rw-r--r--. 1 apache apache 263 Apr 22 11:28 cf91b7b72db9030a680f59a4256653842deb1272e3d96b05874b339be81e8d0e-filelists.xml.gz -rw-r--r--. 1 apache apache 2143 Apr 22 11:28 repomd.xml Actual: Satellite: -rw-r--r--. 1 apache apache 92 Apr 22 11:28 1e25fab79758b4d8ffef13a9dfdca116f1c43c29b29b8ee794989bb27d45ec87-updateinfo.xml.gz -rw-r--r--. 1 apache apache 263 Apr 22 11:28 74db048e56b7cb389cf882b7facea66931588bd220d48f5f6390e937763f0d57-filelists.xml.gz -rw-r--r--. 1 apache apache 244 Apr 22 11:28 87815fc3b9e0ba0a41a6be2c4afb7c1175e1bdf440720de9d418158ae63f8821-other.xml.gz -rw-r--r--. 1 apache apache 124 Apr 22 11:28 a27718cc28ec6d71432e0ef3e6da544b7f9d93f6bb7d0a55aacd592d03144b70-comps.xml -rw-r--r--. 1 apache apache 649 Apr 22 11:28 ac61469eefcac0b9e9fdec558c95ec71245c669ce68031910ca826d12bdb8af5-primary.xml.gz -rw-r--r--. 1 apache apache 2143 Apr 22 11:28 repomd.xml Capsule: -rw-r--r--. 1 apache apache 92 Apr 22 11:28 2aad2c89e394c213631bca0f8f3b4b64ae3ac81c41411333c2fe83d5665d0b8c-updateinfo.xml.gz -rw-r--r--. 1 apache apache 244 Apr 22 11:28 9a4b0e2b8b8c97e4c6ace8d9c027af8aba2a96a9837970f4d0e04a32ce372dba-other.xml.gz -rw-r--r--. 1 apache apache 124 Apr 22 11:28 a27718cc28ec6d71432e0ef3e6da544b7f9d93f6bb7d0a55aacd592d03144b70-comps.xml -rw-r--r--. 1 apache apache 649 Apr 22 11:28 b370f730a9b749b1b1495416711d30c96a3aa6e78ea0b2e6c1db9c27a48f707d-primary.xml.gz -rw-r--r--. 1 apache apache 263 Apr 22 11:28 cf91b7b72db9030a680f59a4256653842deb1272e3d96b05874b339be81e8d0e-filelists.xml.gz -rw-r--r--. 1 apache apache 2143 Apr 22 11:28 repomd.xml Verified on 6.5.0_25.0
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:1222