On Friday, December 21, 2012 12:42:23 PM Michał Górny wrote: > On Fri, 21 Dec 2012 12:31:28 +0100 > > "J. Roeleveld" <jo...@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" <jo...@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
