Bug 1573590 - repositories with immediate download policy do not download during sync
Summary: repositories with immediate download policy do not download during sync
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Repositories
Version: 6.3.1
Hardware: Unspecified
OS: Unspecified
high
high vote
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: vijsingh
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-01 18:20 UTC by Christine Fouant
Modified: 2020-01-15 20:30 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3462391 None None None 2018-05-29 14:06:49 UTC

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.


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