[Pulp-list] Request recommendation for managing repos

[Brian Bouterse]

yum will use all repos it knows about to get the right packages installed
so having Pulp sync+publish OS repos and having applications teams manage
other repos should work fine in terms of deps. There are still several
issues you can run into with this approach. Some will be obvious like yum
will fail to install due to a dependency not being able to be satisfied or
incompatible. Others won't be so obvious like a package 'foo' getting an
update which breaks your application in some way. By delivering the
application and the OS continuously and in parallel to machines you would
just have to fix things after they break.

There is another way, which is an important use case of Pulp. You could
have a testing environment which would test a published OS repo and a
published application repo. This tests the application on top of the
packages a client would receive for the OS or from other application repos.
You can still deliver them independently to the end client, so this would
be using Pulp for controlled testing. As a variation on that idea, you
could take out risk from the yum client at the end by taking the tested OS
and application packages themselves and aggregating them into one larger
repo with package versions that have all been tested together. These types
of workflows make heavy use of the rpm copy functionality of Pulp to copy
packages between repositories so that you can aggregate and promote
packages through dev, test, prod repositories which can each be published
to different sets of machines (dev, test, prod machines).

Hopefully this helps inform some of the options you have. If there are
other questions, let me know.

Best,
Brian



On Wed, Nov 9, 2016 at 12:52 PM, Donald Wolfe <dwolfe at central.com> wrote:

> Group,
>
>
>
> Just got pulp working and am able to update my RHEL/CentOS 6/7 test
> systems now with the help from some of you on this list.  Thank you!!  :)
>
>
>
> Some of our production systems have many third party or application
> related repositories configured in addition to the ones from
> Redhat/CentOS.  My manager has suggested that maybe the application related
> ones should be left to the application teams to manage.  Is it possible or
> recommended to manage some repositories on a system with pulp (to be
> updated periodically on a schedule) while leaving others pointed at the
> original repositories?  What are the potential repercussions around package
> version dependencies, and the like?
>
>
>
>
>
> Thank you, and best regards,
>
>
>
> Don Wolfe
>
> Sr. Unix Administrator
>
> Central Garden and Pet
>
> 1340 Treat Blvd. Suite 600
>
> Walnut Creek, CA 94597
>
> Email:  dwolfe at central.com
>
> Office:  (925) 948-2829
>
> Mobile:  (925) 239-5941
>
>
> Disclaimer: This communication and any attachments contain private,
> confidential, privileged and/or proprietary information intended solely for
> the Recipient(s) named above. If you are not the intended Recipient, any
> use, dissemination, distribution or copying of the communication is
> strictly prohibited. If received in error, we apologize and ask that you
> please notify the Sender by returning this e-mail and permanently deleting
> this communication from your computer, including destruction of any printed
> copies. Any views expressed herein are not necessarily those of the Company
> represented by this e-mail source. No contracts, agreements or legally
> binding understandings may be entered into solely by an e-mail
> communication.
>
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20161210/43f477f9/attachment.htm>