My first target will be sites with existing cells, and that's why I only discuss volumes named "efs.*". When administrators add an existing AFS cell to an EFS domain, they have a one-time task of setting up the top level mount point for "efs.root". Then, EFS will manage that volume, and it's contents, and nothing else.
That's why asserting a simple volume naming convention up front is so important. If EFS can assume that volume's named "efs.*" are all under it's management, then things are pretty easy. We may have to make that prefix configurable of course, but that'll be easy. Let me put it this way. I would like to have EFS self-managing the AFS volumes that belong to AFS for an EFS 3.* release. I think complete, top to bottom AFS cell management would be a 4.* feature. IOW, it's not around the corner. I think what we need to really make this conversation meaningful would be some real world models of existing multi-cell infrastructures. I am still very familiar with Morgan Stanley's basic architecture, but that's a special case and to be honest, probably the easiest one for EFS adopt to, but I don't want to go there.... :-| The "mystery potential clients" that no one will talk about on this public forum are the ones we should obviously model first, and I'll follow up offline and see if I can get something to work with. On Sat, Sep 25, 2010 at 2:38 PM, Steven Jenkins <[email protected]>wrote: > On Sat, Sep 25, 2010 at 11:24 AM, Phillip Moore > <[email protected]> wrote: > > > > I'm splitting up the topics here, just to avoid writing a novel in one > > email.... > > Volume names: the more I think about this, the more I think they should > be > > managed per-domain (EFS domain, that is). One thing EFS *must* assert > for > > a single EFS domain that manages multiple cells, is consistency in the > > directory structure, in the namespace that is /efs. This is core > > functionality for EFS. > > I think that if you make the volume names per-AFS cell, it will just > > complicate the code, and make debugging and diagnosing problems with the > > namespace more difficult. It will also complicate the code and the > database > > significantly. > > One facet of the EFS design I am not willing to change is the conceptual > > idea that an EFS domain is a single, high level administrative domain. > EFS > > is all about bring global consistency to a large enterprise, and I think > > this is an example of enforcing that consistency. I am NEVER going to > > support per-cell, per-region, etc. releasealiases, for example (I > predict > > an annual argument with the user community over this one). > > Having said that, I'll certainly listen to counter arguments for allowing > > the volume names to be cell-specific, but I personally think they should > be > > global. > > > Ah. I was interpreting per domain vs per cell as a different > argument. I completely agree that a given volume name that is 'in' > EFS should be consistent across all cells in the domain. > > There needs to be some thought, though, to how migration of an > existing infrastructure would occur. One could, for example, simply > build out new cells for EFS, but it's worth thinking through how we > might introduce EFS into an existing AFS cell. That would probably > argue for certain volumes (e.g., root.afs, root.cell) being managed > specially for a given cell, and then certain mountpoints existing > under that for the 'legacy' and 'EFS' namespaces. > > But as you say elsewhere, we can speculate forever on how integration > might happen. Better is talking with people who are considering using > it and seeing what their needs actually are. > > Steven > _______________________________________________ > EFS-dev mailing list > [email protected] > http://mailman.openefs.org/mailman/listinfo/efs-dev >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
