Hi,

I think "pulp-admin rpm repo remove rpm" does not work at all.

-> I commented Christina's Bugreport.

I want to use pulp in (almost) the same way, that Christina described in her mail from Aug 6th, which is hardly possible, if I cannot delete obsolete content from repositories.

best regards,
florian

Am 02.12.2013 20:24, schrieb Christina Plummer:

--
!!! ACHTUNG !!!
Die elektronische DKIM-Signatur die der absendende Mailserver der Nachricht beigefügt hat, ist Fehlerhaft. Es handelt sich bei dieser Mail mit großer Wahrscheinlichkeit um eine Faelschung/Spam etc. mx3-phx2.redhat.com ist nicht vertrauenswuerdig!
--

Hi Mike,

I also submitted *Bug 1034978* <https://bugzilla.redhat.com/show_bug.cgi?id=1034978> 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.

Thanks,
Christina


On Tue, Oct 22, 2013 at 11:46 AM, Christina Plummer <[email protected] <mailto:[email protected]>> wrote:

    Thanks; I added some comments to the bug.


    On Mon, Oct 21, 2013 at 8:25 PM, Mike McCune <[email protected]
    <mailto:[email protected]>> wrote:

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





_______________________________________________
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

Reply via email to