Bug 1664127 - productid is not published in the content view if that is the only item which changed in the sync
Summary: productid is not published in the content view if that is the only item which...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Content Views
Version: 6.3.4
Hardware: All
OS: Linux
urgent
high
Target Milestone: 6.4.3
Assignee: Partha Aji
QA Contact: Lai
URL:
Whiteboard:
Depends On: 1659549
Blocks: 1664129
TreeView+ depends on / blocked
 
Reported: 2019-01-07 19:27 UTC by Brad Buckingham
Modified: 2023-09-07 19:37 UTC (History)
7 users (show)

Fixed In Version: tfm-rubygem-katello-3.7.0.52-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1659549
: 1664129 (view as bug list)
Environment:
Last Closed: 2019-04-29 18:15:35 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 26058 0 Urgent Closed productid is not published in the content view if that is the only item which changed in the sync 2020-03-26 18:22:19 UTC
Red Hat Product Errata RHBA-2019:0903 0 None None None 2019-04-29 18:15:41 UTC

Description Brad Buckingham 2019-01-07 19:27:36 UTC
+++ This bug was initially created as a clone of Bug #1659549 +++

Description of problem:
productid is not published in the content view if that is the only item which changed in the sync

Version-Release number of selected component (if applicable):
Satellite 6.3.5

How reproducible:
Always

Steps to Reproduce:
1.We had seen this happen often with kickstart repo like rhel 7.1, rhel 6.9 kickstart repos.
Customer scenario:
- Content view is published and promoted to a lifecycle environment successfully.
- Capsule sync started after the promotion completed

Actual results:
Capsule sync tasks finished with stopped/warning status with /var/log/messages showing. It appears that the productid of the kickstart repo changed in upstream but not other contents. With the current logic of publish to a lifecycle environment, katello thinks there is nothing new to publish to the target lifecycle environment. The orphan clean up job then comes and removes the old productid file in the content view version assuming it wouldn't be used anymore.  But in reality the capsule is still referring to this old product id file and hence the error.


Dec 14 03:57:41 uslp2546403 pulp: nectar.downloaders.threaded:INFO: Download failed: Download of https://satellite.example.com/pulp/repos/Default_Organization/UAT/CV_TEST4/content/dist/rhel/server/7/7.1/x86_64/kickstart/repodata/4c4bc87d3301fd34ca1d49b4787c6f8ee4528e298f031bca447f803b1e374f28-productid.gz failed with code 404: Not Found
...
...
Dec 14 03:57:46 uslp2546403 pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [e28dec63] (10008-26688) Not Found
Dec 14 03:57:46 uslp2546403 pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [e28dec63] (10008-26688) Traceback (most recent call last): 
Dec 14 03:57:46 uslp2546403 pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [e28dec63] (10008-26688)   File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/importers/yum/sync.py", line 263, in run
Dec 14 03:57:46 uslp2546403 pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [e28dec63] (10008-26688)     metadata_files = self.get_metadata(metadata_files)
Dec 14 03:57:46 uslp2546403 pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [e28dec63] (10008-26688)   File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/importers/yum/sync.py", line 450, in get_metadata
Dec 14 03:57:46 uslp2546403 pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [e28dec63] (10008-26688)     metadata_files.download_metadata_files()
Dec 14 03:57:46 uslp2546403 pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [e28dec63] (10008-26688)   File "/usr/lib/python2.7/site-packages/pulp_rpm/plugins/importers/yum/repomd/metadata.py", line 217, in download_metadata_files
Dec 14 03:57:46 uslp2546403 pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [e28dec63] (10008-26688)     raise IOError(error_report.error_msg)
Dec 14 03:57:46 uslp2546403 pulp: pulp_rpm.plugins.importers.yum.sync:ERROR: [e28dec63] (10008-26688) IOError: Not Found
Dec 14 03:57:46 uslp2546403 pulp: pulp.server.async.tasks:INFO: [e28dec63] Task failed : [e28dec63-a96d-4668-a9ee-879fa8a4ef07]
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688) Task pulp.server.managers.repo.sync.sync[e28dec63-a96d-4668-a9ee-879fa8a4ef07] raised unexpected: PulpExecutionException('Importer indicated a failed response',)
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688) Traceback (most recent call last): 
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)   File "/usr/lib/python2.7/site-packages/celery/app/trace.py", line 240, in trace_task
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)     R = retval = fun(*args, **kwargs)
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)   File "/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py", line 527, in __call__
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)     return super(Task, self).__call__(*args, **kwargs)
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)   File "/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py", line 107, in __call__
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)     return super(PulpTask, self).__call__(*args, **kwargs)
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)   File "/usr/lib/python2.7/site-packages/celery/app/trace.py", line 438, in __protected_call__
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)     return self.run(*args, **kwargs)
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)   File "/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py", line 827, in sync
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688)     raise pulp_exceptions.PulpExecutionException(_('Importer indicated a failed response'))
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:ERROR: (9494-26688) PulpExecutionException: Importer indicated a failed response
Dec 14 03:57:46 uslp2546403 pulp: celery.worker.job:INFO: Task pulp.server.async.tasks._release_resource[0b79efb6-2771-4d27-890c-a39cab43f7f9] succeeded in 0.00446466822177s: None

Expected results:
When there is no actual change in the rpm contents and the change happens only in the product id and other metadata contents, they all should be pushed out to right life cycle environments during publish.

Additional info:
Temporary workaround is to re-publish the content view version to the desired lifecycle environment with forced yum metadata regeneration:
hammer content-view version promote --organization-id <id> --content-view-id <id> --version <version_number> --to-lifecyle-environment-id <lce_id> --force-yum-metadata-regeneration

--- Additional comment from Red Hat Bugzilla Rules Engine on 2018-12-14 16:28:18 UTC ---

Since this bug report was entered in Red Hat Bugzilla, the 'sat-backlog' flag has been set to ? to ensure that it is properly evaluated for release.

--- Additional comment from Red Hat Bugzilla Rules Engine on 2018-12-14 16:28:18 UTC ---

Since this issue was entered in Red Hat Bugzilla, the pm_ack has been set to + automatically for the next planned release.

--- Additional comment from Justin Sherrill on 2018-12-14 16:54:32 UTC ---

More details on how you might reproduce the bug:

1.  create some yum repo on disk with a product_id fille
2.  create and sync this repo
3.  Publish the repo in a content view (version 1)
4.  Update/modify the product_id file within the yum repo
5.  Resync the yum repository
6.  Publish the content view again (version 2)
7.  Completely delete version 1
8.  Run the pulp orphan cleanup
9.  Try to download the product id file from the repository or use a client with it

Result, 404 not found

--- Additional comment from Justin Sherrill on 2018-12-17 21:45:17 UTC ---

Created redmine issue https://projects.theforeman.org/issues/25718 from this bug

--- Additional comment from pm-sat on 2018-12-19 19:11:16 UTC ---

Upstream bug assigned to paji

Comment 3 Mike McCune 2019-03-01 22:16:34 UTC
This bug was cloned and is still going to be included in the 6.4.3 release. It no longer has the sat-6.4.z+ flag and 6.4.3 Target Milestone Set which are now on the 6.4.z cloned bug. Please see the Clones field to track the progress of this bug in the 6.4.3 release.

Comment 4 Partha Aji 2019-03-01 22:21:59 UTC
0) Create a repo with the following bash script (Note it doesnot have a productid file)
DIR=/tmp/my-data
mkdir $DIR
cd  $DIR
wget https://partha.fedorapeople.org/test-repos/rpm-with-productid/elephant-0.3-0.8.noarch.rpm
createrepo .
#start serving this dir
python -m SimpleHTTPServer 5050

1) Create and sync repo in sat with feed pointing to http://<fqdn>:5050 
2) put it in a CV and publish and promote to an env
3) now update the repo with a product id. Something like
DIR=/tmp/my-data
cd  $DIR
echo "100000" > productid
modifyrepo  --mdtype=productid productid repodata 

4) resync, publish the CV and promote the new version
5) Go to Monitor -> Tasks view and look for the latest promote 
6) Go to dynflow console Run tab
7) Search for Actions::Katello::Repository::CheckMatchingContent
8) Expand and see check the value of match content 
Expected:
 matching_content: false
Actual:
 matching_content: true


The point here is that "matching_content" value is used to determine whether metadata needs to be republished. However since katello was not tracking stuff in "repodata" directory (aka Yum Metadata) it ignored the fact that a productid file got added there. This fix indexes the yum metadata and thus katello is able to track changes in the repodata directory including productid.

Comment 8 Lai 2019-04-11 21:58:56 UTC
Steps to retest.

0) Create a repo with the following bash script (Note it does not have a productid file)
DIR=/tmp/my-data
mkdir $DIR
cd  $DIR
wget https://partha.fedorapeople.org/test-repos/rpm-with-productid/elephant-0.3-0.8.noarch.rpm
createrepo .
#start serving this dir
python -m SimpleHTTPServer 5050

1) Create and sync repo in sat with feed pointing to http://<fqdn>:5050 
2) put it in a CV and publish and promote to an env
3) DIR=/tmp/this-data
cd  $DIR
echo "100000" > productid
createrepo .
python -m SimpleHTTPServer 5060
3) Change custom repo in sat with feed pointing to http://<fqdn>:5060
4) resync, publish the CV and promote the new version
5) Move productid from this-data to my-data folder
6) Change custom repo in sat with feed pointing to http://<fqdn>:5050
7) resync, publish the cv and promote to the new version
8) Go to Monitor -> Tasks view and look for the latest promote 
9) Go to dynflow console Run tab
10) Search for Actions::Katello::Repository::CheckMatchingContent
11) Expand and see check the value of match content 
Expected:
 matching_content: false
Actual:
 matching_content: false

Alternatively, you can test with this slight modification:

0) Create a repo with the following bash script (Note it doesnot have a productid file)
DIR=/tmp/my-data
mkdir $DIR
cd  $DIR
wget https://partha.fedorapeople.org/test-repos/rpm-with-productid/elephant-0.3-0.8.noarch.rpm
createrepo .
#start serving this dir
python -m SimpleHTTPServer 5050

1) Create and sync repo in sat with feed pointing to http://<fqdn>:5050 
2) put it in a CV and publish and promote to an env
3) now update the repo with a product id. Something like
DIR=/tmp/my-data
cd  $DIR
echo "100000" > productid
createrepo .
modifyrepo  --mdtype=productid productid repodata 
(Add a "createrepo" step so that a new revision number shows up in repomd.xml .)
4) resync, publish the CV and promote the new version
5) Go to Monitor -> Tasks view and look for the latest promote 
6) Go to dynflow console Run tab
7) Search for Actions::Katello::Repository::CheckMatchingContent
8) Expand and see check the value of match content 
Expected:
 matching_content: false
Actual:
 matching_content: false

Verified on 6.4.3_2.0

Comment 10 errata-xmlrpc 2019-04-29 18:15:35 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/RHBA-2019:0903


Note You need to log in before you can comment on or make changes to this bug.