Hi Stephen, thanks for your comments. Burke, S (Stephen) wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Riccardo Zappi said: A) StoRM can manage, at the same time, different VOs. Any VO could use a different set of access protocol.
The problem here is that the available protocols could potentially depend on many different things - VO, share, hardware, network connections, ... and it would be too complicated to allow all possible combinations. Do you think that this kind of thing is really likely in practice? If so, how would you expect it to work? In terms of the schema the easiest thing to represent is probably an ACL (AccessPolicy) on the protocol, so if it would really be a per-VO setting I would prefer to do that rather than having a link between protocol and Share - but still only if we expect it to happen in real deployments. Yes, I posted the above comment because we have a real problem with Glue Schema 1.3.
I try to explain the problem: LHCb don't want RFIO protocol published for its storage areas. I suppose for compatibility reason.. but now it is not important. LHCb want to use FILE protocol for access and GSIFTP for data transfer only. Other supported VOs want RFIO protocol available in addition to FILE and GSIFTP protocols. If we publish RFIO, FILE, and GSIFTP for StoRM service, then all LHCb jobs will fail because they try to use RFIO protocol. Our temporary (I hope ;) ) solution is to use an ad-hoc StoRM installation (and configuration) for LHCb only. I think that this is the only one big limitation of Glue Schema v1.3. You are right about the complicated scenario of supported protocol. I do not know if the use of the AccessPolicy on protocol works. Suppose the scenario where LHCb wants RFIO protocol available for one StorageShare, while for another one LHCb wants only FILE protocol. How can we represent this situation with ACL?
B) DataStore entity should model, in a synthetic and simple form, the concept of the storage hardware (If I've understood well!). I imagine a cluster file system (GPFS for example) installed on a storage area network. In this context, the DataStore is the storage area network plus GPFS. How can define DataStore to include the GPFS characteristics? Using OtherInfo property? Perhaps we can add another property to define the software managing the hardware.
This is exactly the role of the Resource - maybe the name isn't very good but the Resource is supposed to represent the management software. So you would have a Resource for GPFS, with an associated Datastore to represent the disk servers.
In this case, we could define the StorageShare on StorageResource.. or not?
Stephen Riccardo
-- ------------------------------------------------------------------------------- Riccardo Zappi Istituto Nazionale di Fisica Nucleare - CNAF Viale Berti Pichat, 6/2, 40127 BOLOGNA - ITALY Phone: +39-051-609-2868 Fax: +39-051-609-2746 e-mail: riccardo.zappi@cnaf.infn.it -------------------------------------------------------------------------------