[glue-wg] Some doubts

[Riccardo Zappi]

Hi Stephen,
thanks for your comments.

Burke, S (Stephen) wrote:
> glue-wg-bounces at ogf.org 
>> [mailto:glue-wg-bounces at 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 at cnaf.infn.it
-------------------------------------------------------------------------------