Bug 1516803

Summary:	uploading a package to custom repo does not trigger sync of Capsule in Library LE
Product:	Red Hat Satellite	Reporter:	Pavel Moravec <pmoravec>
Component:	Content Management	Assignee:	Samir Jha <sajha>
Status:	CLOSED ERRATA	QA Contact:	Lai <ltran>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	Unspecified	CC:	bbuckingham, dminnich, ehelms, lpurcell, mkearey, mmccune
Target Milestone:	6.5.0	Keywords:	Triaged
Target Release:	Unused
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	tfm-rubygem-katello-3.10.0.24-1	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-14 12:36:46 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:

Description Pavel Moravec 2017-11-23 11:43:35 UTC

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:

Comment 3 Bryan Kearney 2018-11-30 15:01:03 UTC

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.

Comment 4 Pavel Moravec 2018-12-06 11:10:49 UTC

(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.

Comment 5 Pavel Moravec 2018-12-31 12:25:41 UTC

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

Comment 6 Pavel Moravec 2018-12-31 13:00:19 UTC

Upstream issue and PR created with the simple patch; patch itself successfully tested on 6.4.1.

Comment 7 Bryan Kearney 2019-01-15 19:03:23 UTC

Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25761 has been resolved.

Comment 8 Bryan Kearney 2019-01-15 19:04:28 UTC

Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25761 has been resolved.

Comment 9 Bryan Kearney 2019-01-15 19:05:08 UTC

Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25761 has been resolved.

Comment 10 Bryan Kearney 2019-01-15 19:06:08 UTC

Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25761 has been resolved.

Comment 11 Pavel Moravec 2019-01-23 13:39:29 UTC

*** Bug 1621038 has been marked as a duplicate of this bug. ***

Comment 13 Pavel Moravec 2019-01-23 14:32:45 UTC

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

Comment 19 Lai 2019-04-22 17:43:22 UTC

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

Comment 22 errata-xmlrpc 2019-05-14 12:36:46 UTC

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