[Pulp-list] Associating content units between repos using different download policies

[Justin Sherrill]

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 <gmbnomis at gmail.com 
> <mailto:gmbnomis at 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 at redhat.com <mailto:Pulp-list at redhat.com>
>     https://www.redhat.com/mailman/listinfo/pulp-list
>     <https://www.redhat.com/mailman/listinfo/pulp-list>
>
>
>
>
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20171218/75ceb771/attachment.htm>