Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote:
> On Fri, 21 Dec 2012 11:24:45 +0100
>
> "J. Roeleveld" <joost@××××××××.org> wrote:
> > On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
> > > Just let me know when you have to maintain a lot of such systemd
> > > and upgrade, say, glibc. Then maybe you'll understand.
> >
> > A shared /usr means I need to update ALL the systems at once.
> > When /usr is not shared, I can update groups at a time.
>
> Yes, and this is what disqualifies it for the general case. If you
> can't update one at some point, you can't update the others or it is
> going to likely get broken in a random manner.

Yes, but do you want to find out when the entire production environment is 
down? Or would you rather do the upgrades in steps and only risk having to 
rebuild a few nodes and have a lower performance during that time?
There is a big difference between 50% performance and 0%.

> > To save time, a shared filesystem containing binary packages can easily be
> > used and this is what I use myself.
> > I have one VM that is used to rebuild the packages when I want to do an
> > update and the real host then simply uses the binary packages.
> > The configuration items needed for emerge are synchronized between the
> > build system and the actual server.
>
> Wait, wait. So you have introduced even more hackery to get it working?
> Good to hear. That's really a good reason to support your arguments.
> 'I got it working with a lot of hackery, so it is a good solution!'

Please explain, what is hackery about having a single host doing all the 
compiling for multiple servers?
The only thing I need to synchronize between the "real" host and the "compile" 
host is "/etc/portage" and "/var/lib/portage/world"

I don't need any of those to keep the environment running. It's only needed 
during the install/update steps.

> > The main reason why I would never share an OS filesystem between multiple
> > systems is to avoid the situation where a failed upgrade takes down the
> > entire environment.
>
> And this doesn't happen in your case because...? Because as far as I
> can see:
>
> 1) failed upgrade in /usr takes down the entire environment,
>
> 2) failed upgrade in / may take down the machine,
>
> 3) failed hackery you're doing to get it all working may have even more
> unpredictable results.
>
> And yes, I prefer to take down the entire environment and fix it in one
> step. That sounds much better than trying to get it back up and re-sync
> all the machines which got into some mid-broken state.

With shared OS filesystems, that is what you will get.
With non-shared OS filesystems, the other nodes will keep working.

> > And a shared OS filesystem also introduces a very nice Single Point of
> > Failure. What will happen when the NFS-server (or whatever is used) goes
> > down for whatever reason?
>
> And what is the difference now? Is it another argument like 'hey, i can
> still see the command-line, so it's better. not that i can do anything
> useful with it.'

Actually, with a shared OS-filesystem:
When it goes down: "Oops, we lost the entire environment"

With non-shared:
One node goes down: "Oops, we need to fix this node, performance will be down 
while we fix this"
Or "this and that app won't work, but the rest still does"

That's the difference between a major outage impacting the entire company or 
one that only affects a few departments.

> > In other words, to make an environment that has a very nice single point
> > of
> > failure possible, existing working environments are classed as "broken".
>
> NFS-shared system does classify as 'a single point of failure'.

If a single shared filesystem is necessary to be able to use the entire 
environment, then yes.

--
Joost