I don't think any work has been done on it but more comments and
justifications here:
https://bugzilla.redhat.com/show_bug.cgi?id=1004001
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).
Thanks,
Christina
On Tue, Aug 6, 2013 at 1:33 PM, Brian Lee <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[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] <mailto:[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
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
