 |
 |
> Say we propose that for the next LCG-2 release sites should > configure 1000 pool acounts per VO: would any of you object, > and why? Better ideas are welcome too. This seems like a pretty crude fix; it would be problematic for us as UIDs are a comparatively scarce resource. (We keep all UIDs in sync across our departmental machines -- so that we can support NFS, security issues notwithstanding -- and some of those machines are only 16bit-UID capable.) Even if UIDs weren't comparatively scarce, it just seems wasteful to have that many accounts lying around, consuming UIDs, home directories and the like when they won't ever all be used simultaneously. (If they _are_ likely to be used simulataneously, then we've got other problems -- like where the home directory space is going to come from!) Ideally, we'd revise LCG to use a single set of "grid" pool accounts rather than N different sets of VO-specific pool accounts. (where N is the number of VOs that you support.) Under such a system, you would then only need the same number of pool accounts as you have jobs queued on your cluster, rather than N times that many. What currently prevents us from doing this? Cheers, David -- David McBride <[log in to unmask]> Department of Computing, Imperial College, London