As the architect of OpenEFS, I guess I should pipe up and say something... First of all, there's no single solution to this problem, and trying to install *everything* in AFS is possible, but extremeley challenging for some products. This is in fact what we accomplished in the 1990s at Morgan Stanley in the AFS-based distributed environment I helped design and engineer. We went to the ultimate extreme, and even managed the operating system out of AFS by implementing dataless AFS clients. This worked, but proved to be very challenging to maintain.
At the other end of the spectrum, trying to maintain everything local to every node scales far worse, and results in environments with a very large degree of otherwise unnecessary heterogeniety. Now, to put this context, I'm refering to Enterprise environments with 10000+ client nodes distributed in multiple data centers on multiple continents. At medium to small scale (and we would have to debate just what those definitions mean) local installations can be managed fairly well. Classic case of YMMV. My goal has been to design an infrastructure layer that makes both options feasible at large to extreme scale. EFS evolved from the Morgan Stanley VMS system, and the immediate predecessor was implemented using NFSv3 as the backend filesystem, and we focused on open source software and 3rd party vendor products as our content deliverables. We have NOT attempted to integrate the OS with EFS, as I personally think the return on investment is relatively small, and it requires a very significant amount of custom engineering to accomplish. The OpenEFS implementation currently only supports NFSv3 out of the box, but I have done most of the work necessary to use AFS. However, that work is currently on hold, pending, well.. someone else being interested in it. My current employers are very unlikely to invest in an AFS infrastructure, and hopefully I'll find out for sure in early 2011 (I am not very optimistic). We have done a lot of work to automate integrating open source products with OpenEFS, and anything that is built using the GNU autoconf suite or CPAN-style perl packages (Makefile.PL, Build.PL) can be integrated fairly easily. We have a lot of pre-compiled content that be downloaded and used immediately, for example, and we would love to build an open source community around the product. EFS is fundamentally designed to support software deployment and change control in a SINGLE authentication domain, and the goal for OpenAFS is to support distribution to a collection of AFS cells that are all part of the same kerberos realm. This is based on the basic model we used to deploy AFS at Morgan Stanley, where we had a single Kerberos realm but 50+ AFS cells in data centers around the world. The main challenge to using EFS is that it supports a very different deployment paradigm, since it completely decouples software deployment from the clients, but this is precisely why the predecessors to OpenEFS have proven to be successful. If anyone is interested in the product, let us know.... On Mon, Dec 20, 2010 at 1:37 PM, Andrew Deason <adea...@sinenomine.net>wrote: > On Mon, 20 Dec 2010 18:46:32 +0100 > Dirk Heinrichs <dirk.heinri...@altum.de> wrote: > > > I'm currently thinking about a good way to deploy software packages in > > (eventually replicated) AFS volumes. One possible way I can think of > > is to use (x)stow, but that would imply a lot of manual work > > (download, unpack, compile, install to rw volume, xstow, vos release). > > > > Does anyone know of a simpler (more automated) solution, maybe > > something like Gentoo portage or Nix? > > You may be interested in OpenEFS <http://www.openefs.org/>, where I > believe AFS support is being worked on. While you can perhaps get > something to work that just combines something stow-like with > pkgsrc/portage/etc... depending on how 'production' this setup is, > you're going to encounter some problems sooner or later with > dependencies and release engineering, etc, that systems like EFS or VMS > try to make easier. > > -- > Andrew Deason > adea...@sinenomine.net > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info >
