On Fri, Jul 11, 2014 at 8:37 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote: > >> >>> But that would be exactly the thing I'd need to control - and I don't >>> want to control it by having to know anything about the packages ahead >>> of time. For example updating to versions between java1.7u25 and >>> 1.7u55 would have broken an elasticsearch cluster. But I wouldn't >>> have known that ahead of time to use any top-down control. I want to >>> control it by taking a known-good instance, built/tested by some group >>> that knows the details of the component they develop best, and be able >>> to duplicate that system as exactly as possible (allowing for >>> hardware/network/etc. differences), updating some subset of production >>> boxes at a time over some timespan. > > Excuse me: you have completely conflicting requirements. "I want > absolutely consistent control of the packages", vs. "I don't want to > actually know ahead of time what they should be". One has to give. No, you misunderstand. Different groups of people do the build/test component steps than the ones deploying to production. The job of the people doing the deployment is _just_ to duplicate the set of updates that have been tested, not to second-guess what those packages should be (or the OS for that matter). And in between, someone else will pick what subset of machines can have changes at any particular time to avoid conflicts and ensure the ability to roll back. I really do want a tool to just propagate the changes, not control what they are. And due to the scheduling restrictions there may be multiple overlapping revision levels outstanding at any point in time as well as different sets of servers getting different updates. > You can set up a template system (such as a kickstart installed base > system, or a mock repo built chroot cage from locked repositories), > and use that to *derive* your package list. But once you've done that, > you "know ahead of time" what you want on the rest of the sytems, the > ones that you actually want to control configuration of. > > So don't get caught up in that "I don't want to know ahead of time" > idea, because you *have* to know at some point in order to be able to > set the configurations. And as soon as you say "except for > hardware/network/etc.", you need scripting and logic to localize the > settings. No, that's a different set of people. Multiple different sets. I don't want to care (or restrict) how the working systems are assembled or what OS and packages they choose - and couldn't even if I wanted to. I just want to be able to propagate their 'known good' configurations to the production farm according to a planned schedule which will almost never be everything at once. > Since configuration tools like chef, cfengine, puppet, etc., etc. all > make tacit assumptions about your package management that don't have > that much detail, whatever you use needs additional logic. It may as > well be an RPM list, with a bit of logic around hardware drivers, > piped through a shell script, because that's the computing equivalent > of what you want in any more powerful configuration system. Yes, that's my point, None of them do what I want a configuration tool to do. Which I'd think anyone with more than a few machines would want. And given that the packages are versioned and all that needs to happen is that the production updates need to go to the same version numbers that were tested together earlier, it doesn't seem like it should be a difficult thing for a tool to handle for you. But, I don't think there is even anything that will tell you the differences between two systems or verify that they have matching installations at the same update levels. -- Les Mikesell lesmikesell at gmail.com