Issue #1971
closed
'--retain-old-count' option not retroactive
Description
If you update the '--retain-old-count=' option on a previously sync'd repo that has a number of RPM versions greater than the new value, the new value is not retroactive. Currently it appears the only way you can reduce the number of old versions is to delete the repo and re-create/re-sync with the new target value.
Steps to reproduce:
pulp-admin rpm repo create --repo-id=epel-test --feed=http://download-i2.fedoraproject.org/pub/epel/5/x86_64/ --retain-old-count=2 && pulp-admin rpm repo sync run --repo-id=epel-test
pulp-admin rpm repo list --details --repo-id=epel-test | grep 'Rpm'
pulp-admin rpm repo update --repo-id=epel-test --retain-old-count=1 && pulp-admin rpm repo sync run --repo-id=epel-test
pulp-admin rpm repo list --details --repo-id=epel-test | grep 'Rpm'
The RPM count will not change, but should be reduced by 1/3.
You probably don't fully understand functionality of this option. since 'retain_old_cound' is a configuration parameter of yum_importer, when you update its value, yum_importer config is updated and with next sync( since yum_importer is responsible for getting the content into pulp) your change will be taken into account. It is the same as changing 'download_policy' for example. The change will be visible with next sync.
Hi Ipanova, Thanks for the reply.
I chatted with some of the great RH Devs on #pulp and the root of the confusion is that running a repo sync doesn't effect the intended change until the remote repo metadata changes due to an optimization in yum_importer. This isn't intuitive to the user but there is a workaround to trick the importer as discussed in the below IRC passage. Also in the below IRC passage are the plans for a future version of pulp that would head off this problem.
<mhrivnak> KodiakFiresmith, smyers that is a sync setting, not a publish setting.
<mhrivnak> And I bet it's not being applied, because the sync is being skipped.
<mhrivnak> Because the remote metadata hasn't changed.
<KodiakFiresmith> mhrivnak - I tried a sync afterward
...
<mhrivnak> KodiakFiresmith, so I bet the second sync is skipping most of the workflow.
<mhrivnak> There's an optimization where at the beginning, it determines if the remote content has changed or not.
<mhrivnak> If not, it skips most of the workflow.
<KodiakFiresmith> ah - any way to ctrl+F5 a sync?
<mhrivnak> heh
<mhrivnak> We definitely intend to add a --force-full option. I don't remember if that's already in 2.9 or not.
<mhrivnak> There should also be an improvement so that if any config option has changed, it will do a full sync, but again I think that'll land in 2.9 at the soonest.
...
<mhrivnak> you can trick it by doing this: add a type to the skip list with "--skip", sync, remove that from the skip list, and sync again.
--force-full sync option is not implemented yet, we would need to take same approach as we did with publish.
I'm not really privvy to the inner workings as an end-user, this issue was more just me putting it out there that there is an unexpected behaviour happening that might be good to re-work when the big redesign happens w/ Pulp 3.
- Triaged changed from No to Yes
- Related to Story #1982: As a user, I can force a full sync added
- Related to Story #1983: As a user, an importer config change or content removal will cause the next sync to be full added
- Status changed from NEW to CLOSED - WONTFIX
Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is still accepting contributions though, so if you want to contribute a fix for this ticket, please reopen or comment on it. If you don't have permissions to reopen this ticket, or you want to discuss an issue, please reach out via the developer mailing list.
Also available in: Atom
PDF