[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