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? > > > 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. > > > 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*? -- Best regards, Michał Górny
signature.asc
Description: PGP signature
