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