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 <[email protected]> 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 > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-list >
_______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
