[glue-wg] New Endpoint and Service types

Mon Apr 7 13:28:34 EDT 2014

Hi Paul,

Thanks for answering.

I'll cut away parts that I think we discussed enough for the sake of
readability.

On 2014-04-07 17:51, Paul Millar wrote:
> [...]
>> But you should care for consistency, that is the key to a winner model.
> 
> Firstly, consistent with GFD-147, right?
> Secondly, consistent with existing enumeration values.
> 
> In GFD-147, Capability is described explicitly in terms of OGSA
> architecture classification.  OGSA v1.5 spec doesn't include references
> to RFCs.  I would take this to mean we shouldn't publish RFCs under
> Capability.
> 

Well it says "list initially drafted from"

For me consistency with this statement means that the initial state must
be preserved (soundness) and that all the values included in that GFD.80
document should be taken into account (completeness). I didn't read all
GFD.80 and OMII-DJRA2.1, but for what I can see there is no trace of the
strings in GFD.147 as such. So I assume those who wrote GFD.147 used all
the Capabilities they could get from these two docs and shaped them like
what we have now.

I don't see, however
1) Why we cannot add new ones out of these two documents in the GLUE2 spec
2) How would one benefit of a dns-like structure that does not include
functionalities and features (terminology used in GFD.80)

> The description of InterfaceExtension is almost semantically null: "the
> identification of an extension to the interface protocol supported by
> the Endpoint." -- there's nothing about what an extension *is*, but
> there is a hint that this has something to do with protocols.
> 

Agree, very unfortunate: was actually matter of discussion in another
email with Stephen.

> SupportedProfile also has a semantically null description (again, what
> is a profile?), but I can guess what is meant.  RFCs could be published
> as SupportedProfile legitimately, but this probably wasn't the intention
> of this attribute.
> 
> Semantics has the requirement of being human-readable.  This isn't a
> problem for RFCs but, again, probably not what was intended.
> 
> To me, publishing RFCs as InterfaceExtensions is the option most
> consistent with GFD-147.
> 

We can agree on consistency but not on longevity. The main issue here is
that InterfaceExtension is NOT an Open Enumeration, that means is not
supposed to be kept in a defined list of items or a registry like Open
Enumerations.
I agree with Stephen here that this would expose us to a zoo of weird
URLs there -- and you don't need an inexperienced person like me to tell
that this is a very common case with grid service. Do you know that it
took a meeting of four hours to decide which ServiceType_t strings are
the officially accepted?

> 
>>> Likewise, I don't care so much whether the canonical value for RFC2660
>>> is 'rfc2660', 'RFC-2660', 'org.ietf.rfc-2660',
>>> 'Standards.From-IETF.RFC-2660' or 'http://tools.ietf.org/rfc/rfc2660',
>>> provided one purely algorithmic translation is chosen.
>>>
>>
>> I understand all the above comments. However, we are paving the way for
>> GLUE2 to be an unsuccessful schema. The reason is that we keep
>> contradicting what is written in the model, we add hacks and strings the
>> way we like in a non-intuitive way, such that everything can be
>> interpreted in many different ways.
> 
> At the risk of repeating myself: I'm advocating having a single,
> canonical representation for supporting an RFC.  This is then not open
> to being "interpreted in many different ways."  It should be defined
> once and all implementations should use it when publishing their support
> for an RFC.
> 
> I'm not sure of this "keep contradicting ..." but for now my interests
> are in how we publish support for an RFC.
> 

The above is just that I foresee that attributes used in discovery of
Computing Services and Storage Services are becoming completely
different, that for me is a contradiction, because it shows we have no
unifying model.

>> If a capability is a feature then we should enforce that, and not start
>> putting nonsense random strings (org.ogf.rcf-2660 does
>> *not* make sense in that context.)
> 
> I don't understand: what do you mean by "a feature"?  A Capability is
> defined in terms of OGSA, so that's clear.
> 

I am using feature and functionality as it is used in that GFD.80
document. To me what the made-up strings in B.5 try to follow what is a
Capability in that document, that describes features and functionalities
of services. So I am completely with you here.

> 
>> what about
>>
>> protocol.support.rfc2660
> 
> For Capabilities we can't: this string isn't defined in the OGSA v1.5
> document.
> 

I don't see where we decided that we cannot add our own. Being
consistent doesn't mean to be limited to, unless my understanding of
english is not proper.

> For InterfaceExtensions it's OK  (subject to some minor changes)
> 
> However, for InterfaceExtension the value should be a URI.  Technically
> "protocol.support.rfc2600" is a URL, so a URI; however, it would be
> better if the value was either a URL with a schema-part or a properly
> scoped URN.
> 

Exactly. That's why I was actually suggesting it for InterfaceName.

>>>> It would be nice if this is discussed among storage
>>>> services developers.
>>>
>>> There is a meeting coming up, but I'm not sure how much convergence
>>> there'll be.
>>>
>>
>> I wouldn't be surprised. The GLUE2 model as we speak is not even able to
>> bring an agreement among those who created it. Why is that, we should
>> maybe ask ourselves (and I was not part of the making of).
>>
>>> I think it is this groups responsibility to either accept or reject my
>>> view, as expressed above.
>>>
>>
>> It's the group responsibility to bring sanity in this string mess, not
>> to accept or reject someone's opinion. We should rather try to converge
>> to some consistency for the sake of interoperability.
> 
> That's what I'm trying to help facilitate, by providing concrete
> examples and concrete expressions of what I'm trying to achieve.
> 

I didn't say the opposite, I just think it needs more discussion --
unless we decide that the way one discovers and monitors storage is
substantially different from computing services, which for me is a bit sad.

>> WHat do you think about the above formulation, that is, generalize a
>> capability string such as
>>
>> protocol.support.<protocol name>
>> protocol.supported.<rfc name>
>> protocol.supported.<document name>
>>
>> If you have better ideas I'd be happy to follow.
> 
> I think the fundamental problem with Capability is that it's explicitly
> tied to OGSA.
> 

I don't see how and where. It is "Initially drafted from". Maybe I am
missing part of the document?

> [..]

I think we might end up discussing this forever. I trust your opinion as
a storage service developer and the fact that you can bring up this
topic as a member of the group to a more dedicated storage audience.

Mine were just thoughts of the way I'd like to see it. If the community
wants to go in some other way, well fine for me.

I guess it's wise to wait for some decision by the Storage developers
and then take decisions within the group on what to publish.

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