On Thu, Nov 6, 2014 at 7:54 AM, James M. Pulver <jmp...@cornell.edu> 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.)
