[gin-info] gin-jobs use case

[Laurence Field]

Hi Gerson,

> I looked at section 2.2 (Service entity) of the GLUE schema and didn't find the
> ServiceAccessControlRule in there. Has EGEE/LCG extended the GLUE 1.2 spec?
>   
The Glue Service Entry was used before it was officially defined, (very 
naughty!).  So when it came to be defined they decided to use 
GlueServiceOwner instead of GlueServiceAccessControlRule. However, the 
implementations were relying on this so in the schema implementation it 
was put back in, (Very, very, naughty!). However, I think that in 
version 1.3 of the schema it will be correctly defined in the 
specification.

> If we make only our GT4 resource available for job submissions, what should we
> have in the following fields?
>
> ServiceUniqueID: ng2.sapac.edu.au/jobmanager-pbs
> ServiceName: ng2.sapac.edu.au/jobmanager-pbs
> ServiceType: WSGRAM
> ServiceVersion: ??
> ServiceEndpoint:
> https://ng2.sapac.edu.au:8443/wsrf/services/ManagedJobFactoryService
> ServiceAccessControlRule: /GIN
>
>   
This seems okay.

> I'm not sure if the unique ID and the name should be in the format above if the
> service we are publishing is a GT4 service. Something that the GLUE guys
> probably need to address at their F2F meeting.
>   
At the moment the UniqueID just has to be unique, there should be no 
interpretation of the value. We may be able to improve on this in the 
future but I think that what you have defined is fine. This reminds me 
of another issue but I will post that to the list in a separate mail.
> I find the Service entity a bit limited in publishing information about CEs
> because it won't even tell which queue to submit jobs to. Our workaround will
> probably be to check (in pbs.pm) if the user running the job is a member of the
> GIN VO, and if he/she is, the job will be forwarded to short queue.
>   
The request from gin-jobs was that they wanted to find all the resources 
they could access.  How they actually submit the job is their problem 
:). If they need more detailed information about the CE we can give them 
what they need.  The information we have above could be used for 
discovering any service endpoint and it is important that we don't 
pollute this entry with any service specific data.

We could and should preempt the next request from gin-job by thinking 
about  how to describe a CE and I think that can of worms will probably 
be opened during he Glue 2.0 discussions. What we know for sure is that 
the CE description we have now is not ideal. 

Laurence