The background is that a customer of ours is using Katello to synchronize certain Oracle repos, that typically contain many different versions of each package, leading to very large storage sizes on disk.
It appears that pulp_rpm has an option to limit how many versions of the same package are retained.
(Something like retain_old_count for pulp2_rpm, and the retain_package_versions field on a pulp3_rpm remote.)
As far as I can tell, there is nothing in Katello to allow users to easily make use of this Pulp feature.
My question for the Katello community is why that might be? Was there simply never a use case for it, or are there good reasons not to make use of this within Katello?
(For example: I could imagine it clashing with the concept of retaining certain content view states indefinitely, but that is just speculation. I don’t know exactly how the Pulp feature actually operates.)
Does anyone have any pre existing knowledge on this topic?
I only see one problem that can occur and this would be if some package get removed from the synced repository which would be needed in an older content view than content views would lose their value or if they are kept in older content views the expected saved space would be much less. So being conservative on this side would be a good option and could be the reason for not utilizing the Pulp feature in Katello.
Apparently the initial sync of the repo in question is 38GiB vs. 710GiB if one only keeps one version of each package, so in such cases there could still be substantial savings, even if the packages are then kept indefinitely once they make it into a content view.
My best guess is that there simply was not much demand for this feature in the past, given that most people don’t build their repositories that way (with 100s of GiB worth of old package versions).
Unfortunately it is quite common for third party repositories like Puppet, Icinga and others. Not so many use versioned repositories like Foreman. And with “bad” packages like Puppet’s all-in-one package already one package is to big.
So I am totally for having this feature, but it would require a good implementation and documentation, so we avoid errors during configuration.
for having this feature, but it would require a good implementation and documentation, so we avoid errors during configuration.