Thanks; I added some comments to the bug.<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 class="im"><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 class="im">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 class="im"><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 class="im"><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 class="h5">    <<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 class="im">        <<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 class="im">______________________________<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>