Bug 1573590

Summary:	repositories with immediate download policy do not download during sync
Product:	Red Hat Satellite	Reporter:	Christine Fouant <cfouant>
Component:	Repositories	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED WONTFIX	QA Contact:	vijsingh
Severity:	high	Docs Contact:
Priority:	high
Version:	6.3.1	CC:	bbuckingham, cduryee, fhirtz, greartes, riehecky, ttereshc
Target Milestone:	Unspecified	Keywords:	Regression, 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:		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 Christine Fouant 2018-05-01 18:20:34 UTC

Description of problem:

Changing download policy from on_demand to immediate and syncing does not download packages

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


How reproducible: always


Steps to Reproduce:
1. Enable a repository
2. Go to the repository and change the download policy to 'immediate'
3. Sync repository

Actual results:
/var/lib/pulp does not grow

Expected results:
/var/lib/pulp should reflect the content by growing in size

Additional info:

Comment 4 Tanya Tereshchenko 2018-05-02 17:23:49 UTC

Hi Brad, 

I tried to reproduce it on Pulp 2.13.4 and it works for me.
Maybe it depends on how Katello updates importer config. I recall that there were some changes in that area.

Can anyone provide API calls with params which Katello performs during a download policy change?

Is the policy indeed changed on the importer?
Does force_full sync help?
It's worth looking into Pulp logs (journalctl) as well, just in case Pulp failure was not noticed by Katello.

Thanks

Comment 5 Brad Buckingham 2018-05-02 17:27:02 UTC

Thanks Tanya!

Christine, can you assist with this additional data?  If you had already determined it to be an issue isolated within katello, we can move the component back to Repositories.  Thanks!

Comment 7 Frank Hirtz 2018-05-10 13:26:03 UTC

Good morning,

I had a client report this behavior since they were a bit surprised by the change to a default "on_demand" policy and transitioned back to "immediate" but weren't getting the packages. I reproduced locally on my home Satellite for an external yum repo to confirm but didn't debug it at that point aside from noting that "Advanced sync->Sync and validate" in the Satellite repo menu seemed to correct this (but "sync now" does not). What data would we want or need to chase this?

Comment 8 Reartes Guillermo 2018-05-29 02:38:29 UTC

Hi,

I encountered the issue (on 6.3.0) too.
I first changed the default download policy and then changed the policy of each repo. (on_demand to immediate).

It seems that these repos (previously enabled and synchronized) are still using the on_demand policy.

New enabled repos do use the new default immediate.
I will update the Sat6 instance to latest version as soon as i can.

Comment 10 Chris Duryee 2018-06-29 22:44:34 UTC

are you still able to reproduce the issue?

I noticed that if the repo settings are set in a way that is acceptable to Katello but not Pulp, this issue can happen.

Comment 11 Frank Hirtz 2018-09-20 13:04:55 UTC

I didn't see the ping, but I'll give this a try on a current build locally to see if I can reproduce. Previously, I had been able to.

Comment 12 Frank Hirtz 2018-09-20 13:05:44 UTC

Flagging back to 'needinfo' on me.

Comment 13 Frank Hirtz 2018-11-01 18:29:37 UTC

I'm not able to reproduce and have passed a query to the client to see if they've seen this since. I'm suspecting that the answer is 'no' for newer builds, but will confirm to make certain.

Comment 14 Bryan Kearney 2019-12-03 16:34:30 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 Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Comment 15 Bryan Kearney 2020-01-15 20:30:03 UTC

Thank you for your interest in Satellite 6. 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, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.

Comment 16 Bryan Kearney 2020-01-15 20:30:10 UTC

Thank you for your interest in Satellite 6. 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, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.