[Pulp-list] Exclude packages or package groups from repo sync

[Christina Plummer]

Any updates on this one?  I am also looking for a way to avoid syncing the
source RPMs from the Oracle Linux upstream repo, as Brian mentioned.

As a workaround, I tried removing the SRPMs from my repo following the sync
using " pulp-admin rpm repo remove srpm --repo-id=ol5-x86_64 -a 20130901",
but that had no effect (even though " pulp-admin rpm repo content srpm
--repo-id=ol5-x86_64 -a 20130901 " showed me the packages).

Thanks,
Christina


On Tue, Aug 6, 2013 at 1:33 PM, Brian Lee <brian_lee1 at jabil.com> wrote:

> I appreciate the responses. Here are some use cases that I can imagine.
>
> - Users that don't require X Windows for any of their Linux systems would
> prefer not to sync anything that depends on X Windows. These could be
> excluded/blacklisted based on package names, simple pattern matching,
> regex, or yum package groups.
>
> - Some repositories, such as OracleLinux<http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/>include the *.src.rpm in the same repo directory, which makes syncing the
> entire repository *much* larger.
>
> - Users that only want to sync a select few packages from a repository,
> and exclude the rest.
>
> Thanks again,
> Brian
>
>
> On Tue, Aug 6, 2013 at 11:42 AM, Christina Plummer <cplummer at gmail.com>wrote:
>
>> Hi,
>>
>> I am interested in this as well.  I had read an interesting USENIX
>> paper[1] and slidedeck[2] last year about using Pulp to manage yum
>> repositories for enterprise environments, and had hoped to implement
>> something similar.  However, it appears that the features they depend on
>> were only available in Pulp v1.
>>
>> The basic workflow is something like this:
>> 1) Sync all updates from upstream to "live" repo (probably daily)
>> 2) Sync all "non-impactful" updates from "live" (filter out kernel and
>> any other pkgs that we identify as needing more testing) to "unstable" repo
>> (probably weekly - so pkgs are 1 week old before they appear)
>> 3) Sync all "non-impactful" updates from "unstable" after they have been
>> there for a certain time period (weekly or monthly) to "stable" repo
>> 4) Don't point any servers to the "live" repo
>> 5) Point non-production servers to "unstable" repo
>> 6) Point production servers to "stable" repo
>> 7) Manually promote "impactful" packages to "unstable" for testing
>> 8) Manually promote "impactful" packages to "stable" after having been
>> tested
>>
>> As best I can tell, the solution described in the paper is based on "Sync
>> filters", which don't seem to be available in Pulp v2.  So I think the only
>> way to implement something like this would be to use the "copy" feature,
>> which I don't believe can be scheduled.
>>
>> Is it possible to implement this sort of workflow in Pulp v2?
>>
>> Christina
>>
>> [1]
>> https://www.usenix.org/legacy/events/lisa11/tech/full_papers/Pierre.pdf
>> [2] https://www.usenix.org/legacy/events/lisa11/tech/slides/pierre.pdf
>>
>>
>> On Tue, Aug 6, 2013 at 10:47 AM, Randy Barlow <rbarlow at redhat.com> wrote:
>>
>>> On Tue 06 Aug 2013 10:04:48 AM EDT, Brian Lee wrote:
>>> > I believe in older versions of Pulp you could exclude certain packages
>>> > from being synced locally. However, I haven't encountered the method
>>> > for this in Pulp 2.1. To conserve disk space, it would be nice if we
>>> > could exclude packages that match a regex pattern or belong to a
>>> > package group. Let me know if I've just missed this option in the
>>> > documentation or if it's not currently supported.
>>>
>>> Hi Brian,
>>>
>>> We don't currently support this feature, but we have talked about it
>>> before and we are interested in the possibility of supporting something
>>> like this. It would be interesting to use to know your use case, as
>>> there is some difficulty in coming up with a nice way to express what
>>> should be included or excluded from the CLI. You mention package
>>> groups, which makes me also think of package categories. Thanks for the
>>> suggestion!
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20131015/59c9f1ac/attachment.htm>