[Pulp-list] Exclude packages or package groups from repo sync
cplummer at gmail.com
Tue Oct 22 15:46:39 UTC 2013
Thanks; I added some comments to the bug.
On Mon, Oct 21, 2013 at 8:25 PM, Mike McCune <mmccune at redhat.com> wrote:
> I don't think any work has been done on it but more comments and
> justifications here:
> will help prioritize and capture the requirements for the feature
> On 10/15/2013 09:22 AM, Christina Plummer wrote:
>> 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).
>> On Tue, Aug 6, 2013 at 1:33 PM, Brian Lee <brian_lee1 at jabil.com
>> <mailto:brian_lee1 at jabil.com>> wrote:
>> I appreciate the responses. Here are some use cases that I can
>> - 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
>> 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,
>> On Tue, Aug 6, 2013 at 11:42 AM, Christina Plummer
>> <cplummer at gmail.com <mailto:cplummer at gmail.com>> wrote:
>> I am interested in this as well. I had read an interesting
>> USENIX paper and slidedeck 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
>> Is it possible to implement this sort of workflow in Pulp v2?
>> On Tue, Aug 6, 2013 at 10:47 AM, Randy Barlow
>> <rbarlow at redhat.com <mailto: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
>> groups, which makes me also think of package categories.
>> Thanks for the
>> Pulp-list mailing list
>> Pulp-list at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-list