 |
 |
Renata Maria Dart wrote: > Hi Charlie, here is a not-so-brief summary of our recent > AFS experiences with BaBar: > [...] I thought I should add some comments about why we have not pushed the use of read-only clones more heavily. The AFS command to update read-only clones from the read-write volume is 'vos release'. This is a privileged AFS command and the privilege is global, that is, it is not attached to particular volumes: if you've got this privilege, you can vos release any cloned volume in the AFS cell. (IIRC, the same privilege allows you to run opther privileged vos commands.) We have a SLAC-written wrapper, 'vos_release', for the native AFS command that allows AFS package maintainers to do vos releases for the volumes in their packages. The authorization scheme for this wrapper makes use of our naming conventions for package volumes and for the AFS groups in package space. However, AFS group space is much less regular than package space, and our simple wrapper would scale well if we tried to provide fine-grained authorization for vos releases in group space. What we are currently looking into for BaBar is to define a single AFS group whose members would be able to do a vos release for any cloned BaBar volume (all such volume names begin with 'g.bbr'). We have also asked that BaBar keep the number of people in the AFS group small (e.g., 5-10). With this sort of scheme, you probably only want to clone volumes that change infrequently. This, coupled with the need to have clones on all parent volumes, implies constraints on how the space is organized. I hope that helps clarify (and not obscure ;-) some of the issues.