[linux-elitists] Congruent Infrastructure

Marc MERLIN marc at merlins.org
Sun Sep 8 14:05:50 PDT 2013

On Sun, Sep 08, 2013 at 07:24:38PM +0100, Andy Bennett wrote:
> > So the last thing I worked on, was production machines at google. Those are
> > much easier (and unusual because few people do this): they are all the same
> > for the maintained portion.
> Wow. I thought that keeping everything the same was just common sense. I
> figured it was something that was widespread but I'd always come across
> amateurs or people who thought they were operating on too small a scale
> to bother or such a large scale that they thought they couldn't avoid
> the special cases.
The problem is that what we do in prod at google requires everyone to play
along, and basically means that no one can install an rpm or a deb.
In many companies, people would complain if you did that :)
> Why was it important to be able to upgrade without rebooting? Surely you
> have so many machines and are prepared for them to fail and therefore
> can just rotate out a few at a time?
scheduling reboots has to be done carefully. We obviously do reboot for
kernels, but we didn't need or want to reboot for OS upgrades.
I'm pretty pissed when I see ubuntu wanting you to reboot for some not so
important upgrades that really don't require reboot that badly.

> Also, I see you mention "Start with easy packages like 'ed' and 'bc'"
> Don't these come under the heading of "things that made sense to ship as
> part of RH 7.1, but were useless to us" and were therefore already removed?

I'm going to charge you for part of a plane ticket to New Orleans, DC, or
Perth :)
We use bc in some scripts, and ed was mostly kept as a pet and to symlink
emacs to :)
> It seems sensible to manage different layers of the infrastructure in
> different ways. I have long been a fan of epkg (no, not the Gentoo
> thing, this: http://encap.org/ ).
Yeah, I know that one. That's only needed if you don't use a package
manager. We did.

> What do you think of technology like NixOS? It strikes me that it solves
> similar problems to encap but does it in a more complicated way and one
> that forcibly subverts some of the benefits of shared libraries.

I didn't read a lot about it, but it sounds interesting.

> Are shared library benefits, such as the ability to replace a buggy /
> insecure libz, important in large scale infrastructures or do they end
> up being so dwarfed with other operational concerns as to be irrelevant?

shared libraries are complicated. You win some you lose some, it depends how
many users you have and how sure you are that your shared library update is
indeed following the API of the old one and not going to break old clients.
Generally I support shared libraries, but it becomes complicated when
someone needs libfoo.so.1.0 and someone else needs libfoo.so.1.1 for some
obscure reason.
So we did both depending on need.

"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

More information about the linux-elitists mailing list