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

["J. Roeleveld" <joost@antarean.org>]

On Friday, December 21, 2012 12:42:23 PM Michał Górny wrote:
> On Fri, 21 Dec 2012 12:31:28 +0100
> 
> "J. Roeleveld" <joost@antarean.org> wrote:
> > 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@antarean.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%.
> 
> Didn't you just state that you *have* to update all at the same time?

Please re-read what I wrote.
I said, with a *shared* /usr, then yes, I do need to update the entire 
environment at the same time.
With a *non-shared*, this is not necessary.

I also stated that that is one of the reasons why I do not *want* to share 
/usr between multiple hosts.

> > > > 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"
> 
> The hackery is about installing packages partially to local
> and partially to shared location. I feel like I'm not following anymore
> what actually happens there, not that it is worth my time.

That type of hackery is what I do *not* do. Please see above.

> > > > 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.
> 
> Aren't we talking about shared OS filesystems *right now*?

Yes, as a reason why *not* to do it.

I don't ever intend to use a shared OS filesystem. That includes not sharing 
/usr because of the reasons I mentioned.

The main reason mentioned for moving everything and the kitchen sink into /usr 
is to make it easier to share /usr between multiple servers.
Doing that has the side-effect that a seperate /usr will not work without an 
init*.

This makes me conclude that a decision has been made to:
Break existing working environments to support an environment that has a 
built-in single point of failure.

--
Joost