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.
And by the way, I'd not use a 'yum list'. The yum output is difficult to parse, with extraneous and difficult to predict line breaks, unnecessary headers, etc. If you've got to go this way of replicating package lists, use:
rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n'Or use 'rpm -qa --qf '%{name}.%{arch}\n' if you don't care about particular versions.
I sort-of like yum's knowledge of repository the package came from. I just wish it would do something sensible about comparing/duplicating a set. Given that the packages are version, I think there should be a way to do the same operations you do with source version control and for the same reasons.
modulo any differences in hardware related packages and some special cases that are our own local location specific packages. Except for
And this is when you suddenly need something more complex. That's where something more powerful is very useful.
I'd be happy if I could just say 'update' but don't take any packages newer than 'timestamp'. Where 'timestamp' would be the time of the test host update. CentOS is stable enough that I'll take my chances with hardware specific updates that might be different, plus we never update enough systems at once to have a problem with an unforeseen hardware issue.
saltstack, they don't seem that well designed for cross-platform environments and even there windows seems like an afterthought - and it seems sort of fragile the way things can break if you update clients ahead of the server.
Yeah, consistency across environments is difficult. That's where tools like spacewalk can be useful, if only it didn't require so much time and resources to set up in the first place.
Don't think spacewalk is going to help with the windows boxes, and probably not Suse either. And aside from the complexity, I don't think it matches our workflow where many separate groups handle different components on different platforms, all with their own release scheduling. There are probably some tools that could be made to work, but I don't understand them well enough to see how the right steps could be done by the right people to control the update scheduling while ensuring that the changes are exactly what has been tested.
So, I'd really rather have the much simpler capability of being able to repeat a yum update with predictable results.