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

Dennis Kliban dkliban at redhat.com
Mon Dec 18 19:31:30 UTC 2017


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.

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> 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
> 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/6c445dec/attachment.htm>


More information about the Pulp-list mailing list