[glue-wg] GLUE 2.0 Specification - draft 41 - Working Group LastCall

[Burke, S (Stephen)]

Sergio Andreozzi [mailto:sergio.andreozzi at cnaf.infn.it] said:
> - when I instantiate the endpoint, what associations must be 
> instantiated?

I can see that can make sense in some cases, e.g. if there is a
ShareCapacity there must be a Share to attach it to. However, for the
main entities that isn't the case, e.g. you can have a Share without a
Resource or a Resource without a Share, so the relation can't be
mandatory.

> >   All the definitions have a section labelled "Association 
> End" - what
> > does "End" mean there?
> 
> it is borrowed by the UML world.

Maybe it is, but I doubt that most readers will be UML experts ...can't
it just be called "Association"?

> > In fact although the description says that everything inherits
> > from Entity I suspect that excludes Extension? 

[...]

> if Class A inherits from class B, then class A inherits all 
> the class B  attributes *plus* all its associations;

I phrased that badly, what I meant was that Extension does *not* inherit
from Entity even though the text says that everything does. Actually
Paul suggested that maybe Extension should inherit from Entity and there
could be some logic to that - if you did that then you could have
Extensions to Extensions so it would be possible to build a more complex
extension structure.

> I agree with your proposal; I can make the following changes:
> - Rename Key to ID (unless we want ID, Key, Value)

Actually that is what I was suggesting, i.e. to have ID (or LocalID),
Key and Value - we have a general rule that the IDs should not have any
semantics so they shouldn't be keys. Secondly you would need that to
allow the possibility of several Extension objects with the same Key.

> > AdminDomain: I think Owner needs to be defined better.
> 
> what about:
> Identification of the person or legal entity which pays for 
> the services and resources

It still isn't entirely clear what "identification" means - this is
somewhere that examples would help.

> the UserManager is actually an Endpoint.ID and not the URL; 
> therefore it 
> identifies an endpoint class instance with all the info

Well, then it's surely wrong, it should be an association and not an
attribute. Also the structure gets more complicated, you will need a
Service to attach the Endpoint(s) to ... I'd be interested to see what
this would look like in practice. It's also worth remembering that there
may be several VOMS endpoints for a given VO, maybe at different sites,
used for failover.

> > Service: it's not entirely obvious to me why Capability is 
> mandatory.
> 
> let's say that you want to search for all job execution services 
> regardless their interface/implementation;

I can see that you *may* want to search like that, but is this so vital
that we say that everyone *must* publish this for *every* endpoint and
service? For EGEE at least I would think that we'd want this to be
optional.

> > Also I think the enumerated Type list in the appendix is inadequate,
> 
> it is an open enumeration, therefore if values do not match, 
> not problem 
> to publish something extra; it is probably out of scope to provide a 
> complete list;

It can't be complete but I think we should at least cover the standard
cases - what are people supposed to do when they start writing info
providers? They will be stuck at the first step ...

> > And I don't
> > understand why or how Type and Version are combined as a single
> > Interface URI: 

[...]

> this emerged during the revision process with Balazs; one of the most 
> wanted query pattern is: I want to search for an endpoint 
> complying with 
> an interface name an version, plus some extensions as well.

OK, but what's wrong with doing (&(Type=SRM)(Version=2.2.0)) or the
equivalent in other technologies? The whole point of the schema
implementations should be to make queries efficient; putting multiple
items in one attribute just undermines that, effectively you have a
mini-schema within the attribute. In the limit we could have a single
attribute per object with a huge URI that concatenates everything!

> the problem sits mainly in the extensions; by coupling the name and 
> version into one attributes, we can maintain simple properties

That doesn't make much sense to me, an attribute which concatenates
several things is complex, not simple. What if I *don't* care about the
version, just the type? What if I want to do Version>x?

  In any case, you didn't address my point that the Type values *must*
continue to be an enumerated list as they are now - this is really the
core of the entire schema, you can't do anything without knowing what
the endpoint types are.

> I'm not strong on this; TrustedCA is somewhat independent from the 
> policies you set (thought it is related);

It is an access policy, i.e. it specifies who is allowed to access the
endpoint/service. It's true that it's somewhat different in format to,
say, a VOMS FQAN - but we want the Policy object to be generic, so it
should be able to cope with that.

> > And I still think the Downtime attributes
> > should be in a separate object, 

[...]

> this was done also for simplifying the query and because the 
> relationship is 1--1. 

The relationship *isn't* 1-1, there may be several upcoming downtimes
for the same endpoint, you just forced it to be 1-1 (first downtime
only) to make it fit!

> > Share: the Endpoint and Resource relations are marked as mandatory,
> > which doesn't seem right since the objects are supposed to 
> be optional.
> 
> that means, if you instantiate a share, than you must instantiate an 
> association to an existing resource and and existing endpoint;

I'm not sure what you mean by "existing". If you're saying that *if* the
Endpoint and Share both exist then you should fill in the relations too
then I guess that makes sense, but I think it should be clarified that
that is the meaning. However, that doesn't seem to match what you have
for other things, e.g. Service to Endpoint is marked as *, but the same
argument would apply there, *if* Endpoint objects exist for a given
Service then the relation from Service should be filled in, it isn't
optional in that case.

> in this particular case, anyway, this is a kind of "pattern"; 
> share and 
> reource are abstract (and so the relationships) which means 
> not meant to 
> be instantiated, but subclussed

But presumably the subclasses inherit the multiplicities for the
associations?

> about ID/LocalID probably we need more experience; apart a 
> few cases, I 
> don't know when to lean in one direction or in the other

I think there are two cases: you need a unique ID when you have
associations that span across services, or where some external service
like a catalogue may need to store the ID. For Manager, I'm not sure
that either of those apply because you don't access the manager software
directly. For Resource there is in fact a use case that just arose:
Steve Traylen is looking at having a GlueService (basically a gridftp
server) linked to a SubCluster to let people modify the
RunTimeEnvironment tags. In Glue 2 terms ... hmm, I would expect that to
be in the ExecutionEnvironment, i.e. Resource, but in fact I don't see
it - what is supposed to be the Glue 2 equivalent of the RTE?

> here you raise a new possible use case: do we want to allow 
> to publish a 
> service with no endpoint and no share, but a manager and a resource?

At least, I'm not sure we should forbid it at the schema level. (A
read-only classic SE which only supports NFS access?)

> given the assocations multiplicity, at the moment we can have:
> 
> 1. Service
> 2. Service + Endpoint
> 3. Service + Endpoing + Manager + Resource

I think we should allow Manager without Endpoint (classic SE with NFS,
CE with local submission only, ...)

Stephen