On 12/18/2017 02:31 PM, Dennis Kliban wrote:
The use case you are describing is not one that Pulp 2 currently
supports. However, I can picture this feature working in 2 different ways:
1) A publisher for a repository with an 'immediate' download policy on
an importer should make sure that all the content it is publishing is
actually downloaded.
2) A copy of content from an 'on_demand' repo to an 'immediate' repo
should schedule the copied units to be downloaded.
Could you issue a 'download repo' task to one of the secondary repos to
force those units to download?
pulp-admin repo download
Note that this is *different* than 'pulp-admin rpm repo sync'
It wouldn't be automatic, but could be scheduled.
-Justin
What do others think? Is there another way to solve this problem?
-Dennis
On Mon, Dec 18, 2017 at 8:09 AM, Simon Baatz <gmbno...@gmail.com
<mailto:gmbno...@gmail.com>> wrote:
We are trying to optimize one of our use cases using Pulp's
'on_demand' download policy, but it does not work as expected (I
reckon that's because the deferred download feature was designed for a
different use case).
We have one or even multiple large 'source' RPM repos from which we
associate a much smaller number of RPMs into a dedicated 'destination'
repo. We then publish (locally and using rsync distributors) the
'destination' repo, which is used for installation on our servers.
Up to now, the source repos sync from their feeds using 'immediate' as
download policy. As we only need a small subset of the RPMs, we tested
to set the download policy to 'on_demand' on the source repos in order
to download the needed RPMs only. We kept 'immediate' for the
'destination' repo we are associating RPMs into.
However, associating an RPM into that repo does not trigger a download
(neither immediately nor by the 'deferred_download' task). Publishing
the 'destination' repo works and content can be downloaded even though
the download policy is set to 'immediate' (i.e. squid/pulp_streamer
will deliver the content unit as long as it is not present). The rsync
publisher fails however, because most of the symlinks are pointing
to non-existent destinations.
As a workaround we tried to use another repo whose feed points to the
'destination' repo and sync it. This will cause Pulp to download and
store the needed RPMs.
Basically, I have two questions:
- Is this how association between repos with different download
policies is supposed to work? (I would have expected this to not
work at all or to trigger downloading)
- If so, is there a more direct way to ensure or trigger the
download of
all RPMs in our destination repo?
Btw., we tested this on Pulp 2.14.3.
- Simon
_______________________________________________
Pulp-list mailing list
Pulp-list@redhat.com <mailto:Pulp-list@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-list
<https://www.redhat.com/mailman/listinfo/pulp-list>
_______________________________________________
Pulp-list mailing list
Pulp-list@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list
_______________________________________________
Pulp-list mailing list
Pulp-list@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list
