Bug 1803988

Summary:	Changing on-demand to immediate not working with broken symlinks
Product:	Red Hat Satellite	Reporter:	Partha Aji <paji>
Component:	Pulp	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED WONTFIX	QA Contact:	Lai <ltran>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.7.0	CC:	jdickers, ltran, ttereshc
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-03-18 19:44:22 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 Partha Aji 2020-02-17 22:55:31 UTC

I created a bad repo the following way
"""
$ wget https://repos.fedorapeople.org/repos/pulp/pulp/stable/latest/7Server/x86_64/pulp-python-admin-extensions-2.0.3-1.el7.noarch.rpm
$ wget https://repos.fedorapeople.org/repos/pulp/pulp/stable/latest/7Server/x86_64/pulp-puppet-consumer-extensions-2.21.0-1.el7.noarch.rpm
$ wget https://repos.fedorapeople.org/repos/pulp/pulp/stable/latest/7Server/x86_64/python-pulp-ostree-common-1.4.0-1.el7.noarch.rpm

$ createrepo .
$ rm python-pulp-ostree-common-1.4.0-1.el7.noarch.rpm
"""
I also did 'python -m http.server 2020' so that the contents are available via http


On Satellite:
1) Create Repo pointing to http://<fqdn>:2020
2) Mark it as On Demand
3) Sync 
4) Get the backend identifier of the repo from repo details and look at 'ls -l /var/lib/pulp/published/yum/master/yum_distributor/<backend_identifier>/<...>/Packages/p'
you should see 3 broken symlinks
5) Now change the Repo to immediate and resync which should fail with a warning. Feel free to try complete sync also.

6) 'ls -l /var/lib/pulp/published/yum/master/yum_distributor/<backend_identifier>/<...>/Packages/p' 

Expected:
2 files in that directory and no python-pulp-ostree-common-1.4.0-1.el7.noarch.rpm

Actual:
There is still a bad symlink for python-pulp-ostree-common-1.4.0-1.el7.noarch.rpm

The larger issue here is the effect on capsule syncing if syncing was changed from On Demand to Immediate

Comment 3 Partha Aji 2020-02-17 22:57:42 UTC

Forgot to add a step

"""
$ wget https://repos.fedorapeople.org/repos/pulp/pulp/stable/latest/7Server/x86_64/pulp-python-admin-extensions-2.0.3-1.el7.noarch.rpm
$ wget https://repos.fedorapeople.org/repos/pulp/pulp/stable/latest/7Server/x86_64/pulp-puppet-consumer-extensions-2.21.0-1.el7.noarch.rpm
$ wget https://repos.fedorapeople.org/repos/pulp/pulp/stable/latest/7Server/x86_64/python-pulp-ostree-common-1.4.0-1.el7.noarch.rpm

$ createrepo .
$ rm python-pulp-ostree-common-1.4.0-1.el7.noarch.rpm
$ touch foo; ln -s foo python-pulp-ostree-common-1.4.0-1.el7.noarch.rpm; rm foo
"""

Comment 4 Partha Aji 2020-02-18 22:58:09 UTC

1) If I synced a repo with "immediate" download policy AND  if the upstream repo had a broken/invalid symlink, pulp correctly does not try to pull that file to the disk. 

2) On the other hand on-demand sync does not really know that the upstream link is broken. It just notices that there is a file that is supposed to exist according to the repodata primary xml and put a "placeholder" symlink for that link.

3) In the above case in comment 1 the User set it to On-Demand, synced (creating placeholder links) and then switched it to Immediate and resynced.  In this case I would expect the behaviour to be similar to case 1. Remove the bad symlink and treat it as you would for straight up immediate.

Comment 5 Tanya Tereshchenko 2020-02-24 12:33:35 UTC

Partha, after switching to Immediate, in which mode do you sync, mirror or not?

Comment 6 Mike McCune 2022-01-28 22:30:40 UTC

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team. Thank you.

Comment 7 Mike McCune 2022-03-18 19:44:22 UTC

Thank you for your interest in Red Hat Satellite. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to contact your Red Hat Account Team. Thank you.

Comment 8 Red Hat Bugzilla 2023-09-15 00:29:39 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days