On Fri, 2014-07-11 at 14:38 -0500, Les Mikesell wrote:
On Thu, Jul 10, 2014 at 5:46 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
So you are saying that the system does not have its own sane way to manage packages?
Most do. But there are often subtle implications. The chef "java" cookbook, for example, has no option to set a particular RPM release number, only to select a basic java "7" or "6" major release, and to select the openjdk or Oracle versions. When the original author did not appreciate the desire for more granularity, it can be very difficult to get the subtleties like particular Java release installed as needed.
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.
Hello,
So I haven't fully followed the thread and thus may not be helping. However I think what you are looking for is called ostree. I have never personally used it but I think it fills the niche you are looking for which is a broad set of testable updates. No idea of the pros/cons but may be what you want to look at.