On Thu, Nov 6, 2014 at 7:54 AM, James M. Pulver <[log in to unmask]> wrote:
>
> Quote:
>
> Let me offer a suggestion that may help for production environments.
> Use something like "rsnapshot" to make locked copies of an rsync mirror of Scientific Linux, and ensure that your local yum setup is aimed at a locked down version of the local repo whose contents have been evaluated. It takes thought and a configuraiton management tools like cfengine or puppet or chef, but it can be done.
>
>
> Is this sort of thing where Katello is trying to make more dynamic or maybe more flexible? We're using Puppet and finding that specifying versions of software in manifests works, but is less than ideal. Yes, we could parameterize them, but I think a smarter repo structure like Katello seems to be for would be more ideal and elegant...

I sympathize with Katello's situation, I've had to deal with it
personally, big time. (When you've got thousands of servers scattered
over years of manufacture from different vendors, you *have* to test
things.)

It's not feasible to rely on the upstream vendor, RHEL, to enforce
compatibility with third party repos, especially if you're not paying
them, and SL and CentOS are in the same position. They can't possibly
maintain a build lab with all the combinations of third party software
and high end and older hardware. That gets *expensive* very, very
fast, and they can't possibly make their published updates based on an
out of band 3rd party repo.  (Been there, done that for render
clusters and CGI workstations: ask about Wacom graphics tablets some
time if you get curious.)

Ideally, you invest in the open source process and do it yourself for
your own enviroment. Invest in a test host, ideally your own, and
stage updates to happen there first. Find the incompatibilities,
report them upstream, and *then* release the updates for your general
environment. Many folks do this for their Windows and other tools,
where they accept the risk of delaying updates to test them first in
smoke test environments, and only *then* apply them to the general
network.

It needs something like "rsnapshot" to take staged snapshots from
upstream, and some designated procedure to rename or replicate with
'cp -al' the designated, tested build after it's gone through testing.
And it needs some out of band way to designate which build to use, and
to tune the build if needed. (In this case, to exdclude the unworkable
kernel update until El Repo can be updated.)