Hacker News Reader

Comment by Annatar | Hacker News Reader

Even worse, on Linux, most packages will be helpful, for example upgrading the MongoDB package on CentOS? It'll helpfully restart the service for you. Nevermind that you've just scripted this and it's being run on all of the servers all at once so instead of doing a nice easy rolling upgrade WHEN you are finally ready, it's done at the same time.

That’s exactly how it must work for total automation where humans are out of the picture. What you lack is a push, rather than a pull methodology, with a software deployment server and a capability maturity model level 3 (or higher) change management process around it. Then it works flawlessly, and I’m writing from experience of several decades of modelling and implementing such things on a very large scale (tens or even hundreds of thousands of servers).

That’s my specialty as a technical architect.

https://en.m.wikipedia.org/wiki/Capability_Maturity_Model

View on HN

I have other bits of software that manage that part for me, as part of my automation.

Why would I expect a package manager to also restart my services?

I need to make sure that other parts of the stack can either handle that service going away gracefully, or have automation around it, my package manager can't know the dependencies in which certain services should be stopped/started for example to allow for graceful failover. It's illogical to try and place all of that logic in the package manager, that is not its job. Especially if there are other config changes that need to happen too that are not part of that package management system.

Humans can still be out of the picture without a package manager starting/stopping/restarting services. Your suggestion of it being part of a maturity model don't make sense. I asked for the package to be upgraded, not for the service to be restarted.

Doing it through the package manager presents a uniform interface through one single command. Executing ordinary shell scripts through the package’s postinstall minimizes dependencies (no Puppet, Chef or CFengine required) and makes it easier on system administrators who do not have to learn any of those applications to perform system maintenance or perform telemetry gathering as directed by system engineering department. Doing or calling configuration scripts inside of OS packaging ensures that the system knows about and can be queried through its standardized software management subsystem as to what has been done to it, where, and by whom (component owner will be in the package metadata).

For example: a package delivers /opt/abcd/sbin/pgadm, which would be your engineered command line interface to CREATE DATABASE, database backups, and so on; then the application-db package calls that in its postinstall to create a database specific to that application. Best of all, once one has such packages, they can be plugged into Kickstart, JumpStart, AutoYaST, or whatever the OS provides for automated provisioning and hardware whether physical or virtual, turned into fully configured systems from literally nothing with no special or custom provisioning required. You could lose entire networks of servers and prop them up in seconds again this way.

Reply on news.ycombinator.com