[glue-wg] New Endpoint and Service types

Florido Paganelli florido.paganelli at hep.lu.se
Wed Mar 5 14:23:00 EST 2014


Hi all,

I agree with Stephen on all the comments and questions.

Cheers,
Florido

On 2014-03-05 19:10, stephen.burke at stfc.ac.uk wrote:
> Paul Millar [mailto:paul.millar at desy.de] said:
>> Stephen, to you DPM, dCache and Castor provide the same 
>> functionality, 
>> so you would be happy with instances of all three published as 
>> Service.Type of 'storage' (or similar).
> 
> Not entirely - the object names are prefixed with "Storage" anyway, so simply publishing a Type of "storage" would be redundant. Also it seems to me that something like a standalone xrootd server or a "classic SE" as we used to have would reasonably be different types of storage service, even aside from the details of which protocols they support. However, we do have a family of SRM-based SEs which seem to me to represent a commmon type - indeed I thought that one of the goals of EMI for dcache, DPM and StoRM was precisely to make them interoperable! In the past I would have suggested "SRM" as a Type, but since we now seem to be making moves away from the use of SRM that may not be ideal as a name. From a dcache POV, what do you see as providing commonality with DPM and StoRM? (Beyond all being storage systems.)
> 
>> Somebody who needs some unique characteristic provided by dCache (or 
>> DPM, or ...) might want more detailed Type, specifically that the 
>> service provides the dCache-like facilities (or DPM-like or ...).
> 
> If someone really wants to know the implementation they can look at the EndpointImplementationName or ManagerProductName - although of course it's undesirable to have anything which is implementation-specific. For me, to be a valid type it would have to be the case that a completely different vendor could potentially produce an independent product which could reasonably be described as "a DPM" or "a dcache" - even conceptually, can you see such a thing as being meaningful? If so, how would you define it? You use "dcache-like" above, but what does that mean (in terms of external interfaces)?
> 
>> For the xrootd protocol, dCache currently publishes
>>
>>      Endpoint.URL: xroot://xrootd-door.example.org/
>>      EndpointInterface.Name: xroot
>> and StorageAccessProtocol.Type: xrootd
> 
> What protocol name do you recognise in e.g. a getTURL operation to return an xroot TURL? Does it match what DPM and StoRM use? What about webdav?
> 
>> For WebDAV, dCache is currently publishing as either 'http' 
>> or 'https', 
>> depending on whether SSL/TLS tunnelling is enabled or not.  
> 
> Bear in mind that the scheme name in the URL is not the same as the InterfaceName. I don't know a lot about webdav but my impression is that it's far from being identical with http as far as file access goes, so I would expect a different InterfaceName even if the URL is https:// (c.f. SRM vs. httpg://).
> 
>> When publishing an Endpoint object the describes an HTTP or a WebDAV 
>> endpoint with unencrypted access then the URL SHOULD start 
>> 'http://' and 
>> the InterfaceName SHOULD be 'http'.  If the endpoint is 
>> encrypted then 
>> the URL SHOULD start 'https://' and the InterfaceName SHOULD 
>> be 'https'. 
>>   If the endpoint supports WebDAV then a SupportedProfile of 
>> 'http://webdav.org/' SHOULD be published.
> 
> If it's necessary to make that distinction think I would prefer to publish both http and webdav endpoints, doing it your way would seem likely to be error-prone.
> 
> Stephen-- 
> Scanned by iCritical.
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg
> 


-- 
==================================================
 Florido Paganelli
   ARC Middleware Developer - NorduGrid Collaboration
   System Administrator
 Lund University
 Department of Physics
 Division of Particle Physics
 BOX118
 221 00 Lund
 Office Location: Fysikum, Hus B, Rum B313
 Office Tel: 046-2220272
 Email: florido.paganelli at REMOVE_THIShep.lu.se
 Homepage: http://www.hep.lu.se/staff/paganelli
==================================================


More information about the glue-wg mailing list