<div dir="ltr">Hi Mike,<br><br>I also submitted <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1034978"><b>Bug 1034978</b></a> for the problem I had with not being able to remove source RPMs an existing repo. I wasn't able to find any other bugs for the issue.<br>
<br>Thanks,<br>Christina<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 11:46 AM, Christina Plummer <span dir="ltr"><<a href="mailto:cplummer@gmail.com" target="_blank">cplummer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks; I added some comments to the bug.<div class="HOEnZb"><div class="h5"><br><br>
<div class="gmail_quote">On Mon, Oct 21, 2013 at 8:25 PM, Mike McCune <span dir="ltr"><<a href="mailto:mmccune@redhat.com" target="_blank">mmccune@redhat.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">I don't think any work has been done on it but more comments and justifications here:<br><br><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1004001" target="_blank">https://bugzilla.redhat.com/<u></u>show_bug.cgi?id=1004001</a><br>
<br>will help prioritize and capture the requirements for the feature
<div><br><br>On 10/15/2013 09:22 AM, Christina Plummer wrote:<br></div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div>Any updates on this one? I am also looking for a way to avoid syncing<br>the source RPMs from the Oracle Linux upstream repo, as Brian mentioned.<br><br>As a workaround, I tried removing the SRPMs from my repo following the<br>
sync using " pulp-admin rpm repo remove srpm --repo-id=ol5-x86_64 -a<br>20130901", but that had no effect (even though " pulp-admin rpm repo<br>content srpm --repo-id=ol5-x86_64 -a 20130901 " showed me the packages).<br>
<br>Thanks,<br>Christina<br><br><br>On Tue, Aug 6, 2013 at 1:33 PM, Brian Lee <<a href="mailto:brian_lee1@jabil.com" target="_blank">brian_lee1@jabil.com</a><br></div>
<div><mailto:<a href="mailto:brian_lee1@jabil.com" target="_blank">brian_lee1@jabil.com</a>>> wrote:<br><br> I appreciate the responses. Here are some use cases that I can imagine.<br><br> - Users that don't require X Windows for any of their Linux systems<br>
would prefer not to sync anything that depends on X Windows. These<br> could be excluded/blacklisted based on package names, simple pattern<br> matching, regex, or yum package groups.<br><br> - Some repositories, such as OracleLinux<br>
</div> <<a href="http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/" target="_blank">http://public-yum.oracle.com/<u></u>repo/OracleLinux/OL6/latest/<u></u>x86_64/</a>>
<div><br> include the *.src.rpm in the same repo directory, which makes<br> syncing the entire repository *much* larger.<br><br> - Users that only want to sync a select few packages from a<br> repository, and exclude the rest.<br>
<br> Thanks again,<br> Brian<br><br><br> On Tue, Aug 6, 2013 at 11:42 AM, Christina Plummer<br></div>
<div>
<div> <<a href="mailto:cplummer@gmail.com" target="_blank">cplummer@gmail.com</a> <mailto:<a href="mailto:cplummer@gmail.com" target="_blank">cplummer@gmail.com</a>>> wrote:<br><br> Hi,<br>
<br> I am interested in this as well. I had read an interesting<br> USENIX paper[1] and slidedeck[2] last year about using Pulp to<br> manage yum repositories for enterprise environments, and had<br>
hoped to implement something similar. However, it appears that<br> the features they depend on were only available in Pulp v1.<br><br> The basic workflow is something like this:<br> 1) Sync all updates from upstream to "live" repo (probably daily)<br>
2) Sync all "non-impactful" updates from "live" (filter out<br> kernel and any other pkgs that we identify as needing more<br> testing) to "unstable" repo (probably weekly - so pkgs are 1<br>
week old before they appear)<br> 3) Sync all "non-impactful" updates from "unstable" after they<br> have been there for a certain time period (weekly or monthly) to<br> "stable" repo<br>
4) Don't point any servers to the "live" repo<br> 5) Point non-production servers to "unstable" repo<br> 6) Point production servers to "stable" repo<br> 7) Manually promote "impactful" packages to "unstable" for testing<br>
8) Manually promote "impactful" packages to "stable" after<br> having been tested<br><br> As best I can tell, the solution described in the paper is based<br> on "Sync filters", which don't seem to be available in Pulp v2.<br>
So I think the only way to implement something like this would<br> be to use the "copy" feature, which I don't believe can be<br> scheduled.<br><br> Is it possible to implement this sort of workflow in Pulp v2?<br>
<br> Christina<br><br> [1]<br> <a href="https://www.usenix.org/legacy/events/lisa11/tech/full_papers/Pierre.pdf" target="_blank">https://www.usenix.org/legacy/<u></u>events/lisa11/tech/full_<u></u>papers/Pierre.pdf</a><br>
[2]<br> <a href="https://www.usenix.org/legacy/events/lisa11/tech/slides/pierre.pdf" target="_blank">https://www.usenix.org/legacy/<u></u>events/lisa11/tech/slides/<u></u>pierre.pdf</a><br><br><br> On Tue, Aug 6, 2013 at 10:47 AM, Randy Barlow<br>
</div></div>
<div> <<a href="mailto:rbarlow@redhat.com" target="_blank">rbarlow@redhat.com</a> <mailto:<a href="mailto:rbarlow@redhat.com" target="_blank">rbarlow@redhat.com</a>>> wrote:<br><br> On Tue 06 Aug 2013 10:04:48 AM EDT, Brian Lee wrote:<br>
> I believe in older versions of Pulp you could exclude certain packages<br> > from being synced locally. However, I haven't encountered the method<br> > for this in Pulp 2.1. To conserve disk space, it would be nice if we<br>
> could exclude packages that match a regex pattern or belong to a<br> > package group. Let me know if I've just missed this option in the<br> > documentation or if it's not currently supported.<br>
<br> Hi Brian,<br><br> We don't currently support this feature, but we have talked<br> about it<br> before and we are interested in the possibility of<br> supporting something<br>
like this. It would be interesting to use to know your use<br> case, as<br> there is some difficulty in coming up with a nice way to<br> express what<br> should be included or excluded from the CLI. You mention package<br>
groups, which makes me also think of package categories.<br> Thanks for the<br> suggestion!<br><br><br><br><br><br></div>
<div>______________________________<u></u>_________________<br>Pulp-list mailing list<br><a href="mailto:Pulp-list@redhat.com" target="_blank">Pulp-list@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/pulp-list" target="_blank">https://www.redhat.com/<u></u>mailman/listinfo/pulp-list</a><br>
<br></div></blockquote></blockquote></div><br>
</div></div></blockquote></div><br></div>