[glue-wg] Enumerations for DPM and related InterfaceNames was: Re: New Endpoint and Service types

Fri Apr 4 11:42:17 EDT 2014

Hi Stephen,

Thanks for the comments. Some thoughts:

On 2014-04-04 16:45, stephen.burke at stfc.ac.uk wrote:
> Florido Paganelli [mailto:florido.paganelli at hep.lu.se] said:
>> the group would like to have an organization name. It has beed
>> decided that if there is no organization name, then one can
>> fallback to the group reserver organization name, that can be used
>> for orphan projects.
>> 
>> therefore we suggest:
>> 
>> org.ogf.glue.dpm
>> 
>> What do people think about this?
> 
> As I've said before, the ServiceType is only going to be useful if
> there is a need to identify a set of services which is bigger than a
> single implementation and smaller than the universe of all Services
> (or all Storage Services in this case). It may be that there is no
> such need, in which case we may as well use a ServiceType based on
> the implementation name (we have to publish something, it's a
> mandatory attribute).
> 
> In any case, there's a meeting of the storage providers organised by
> Maria to discuss this kind of thing in a couple of weeks
> (https://indico.cern.ch/event/311528/), so we should wait to see what
> comes out of that.
> 

Ok, let's wait and see.

>>> - "org.webdav" and "org.xrootd" to InterfaceName
>> 
>> This I completely fail to understand.
>> 
>> webdav and xrootd are protocol names. Why would they be 
>> interfacenames? An interface name is an "identification of the
>> Interface" as GDF.147 says. org. is not an organization.
> 
> I don't understand your point. InterfaceNames are often protocol
> names, although they may be more restricted to indicate a specialised
> use, for example the BDII uses LDAP as a protocol but the
> InterfaceNames are bdii_site and bdii_top (which aren't especially
> well-formed but have been in use for a long time). In general, if an
> Interface is specific to a particular product or project then we
> would prefer the Name qualified by a DNS-style prefix to avoid name
> clashes (not because the name has any significance).
> 

ok. But from me as a developer (I was not yet member of the group)
reading the GLUE2 spec I though ok, any random name can go there -- as
nowehere in the document the word "protocol" is ever coupled with
"InterfaceName" -- again, in my opinion this is badly managed by the
group and brings lots of confusion.
It is a mandatory attribute!

> For standard well-known protocols like say http there is no need for
> any prefix as there's no likelihood of a clash. Arguably xroot is not
> such a general standard, but we long ago agreed on "xroot" as the
> name, it's been in use for many years and I think there's little
> chance of a clash.
> 

I see

> As we already discussed, webdav is a different case. It's certainly a
> standard, but it remains undecided whether we regard it as an
> interface in its own right or as a subset of http (and/or https?).
> 

Publishing the subset is wrong. It is misleading.

>> now, we have dCache publishing: xroot as interface name, which I
>> think is as bad as the above.
> 
> Since that is what we specified, dcache is correct.
>
>> This needs severe sanitization.
> 
> No. For established names that have been in use for a long time I
> think changing them would be a very bad idea, it gains nothing and
> would be disruptive for a long time. Past experience with trying to
> rename things is that it's nearly impossible to remove all traces of
> the old name, so I would say that it should only be considered where
> there's an overriding reason. (Also note that the GOC DB has decided
> not to bring its names in line for the same reason.)
> 
>> My suggestion for these two InterfaceNames would be:
>> 
>> org.ogf.glue.dpm.webdav org.ogf.glue.dpm.xrootd
> 
> No, that would be crazy - these are *standard* protocols, they are
> not in any way specific to DPM, so they need to have universal
> names.
> 

I understand. But then in the next review of the spec let's put that
this is a protocol name and not the fuzzy identification thing that is
there now.
We might keep the word "identification" but let's put examples at least.

We will need to add rules for interfaces that support multiple
protocols, i.e. these protocols must be specified as Capabilities?

The most obvious thing is that one should publish an endpoint for each
interfaceName.

>> How they can be used in discovery I already said in several
>> emails. InterfaceName should NOT be used to indentify the protocol
>> or the cababilities. For that there is existing attributes.
> 
> This is nonsense - InterfaceName is precisely the agreed attribute to
> identify the protocol.
> 

I never read it anywhere as a developer, I'm sorry Stephen. For me is
just another string. After this clarification and 3 years of working
with this I just realized we still don't have a common point of
view on concepts. The fact that historically communities using GLUE2
made some choices are not visible to an external reader.

So in conclusion:
1) we wait for this storage meeting
2) We keep those protocol names as interfacenames for the reasons you
explained.

Fair enough for me, but I just think that currently:
- InterfaceName it is of no real use for discovery for
  inconsistenciens  across implementors: some put a well known
  protocol name, some a weird string; if you don't belong to the
  community who created the rendering you just don't understand what
  that is about

- imposes strict rules on implementations (multiple protocols =>
  multiple endpoints)

- does not suggest a way to publish protocol information -- this is
  something we only knew because we belong to the community using it,
  but is never mentioned in the spec.

Cheers,
-- 
==================================================
 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
==================================================