Hi Gerson, Gerson Galang wrote:

Thanks for integrating our requirements into the new GLUE 2.0 spec. What you have in the draft will work for us now.

The only thing I want to comment on is the ComputingShare's relationship with the ComputingResource and ComputingService entities. If a ComputingShare is an abstraction of a queue

this is not always the case. That's why we have a different naming/definition. For instance, in the LSF batch system you can use hierarchical fair sharing in order to define different utilization targets for jobs entering the same queue. The scheduling will consider the group to which the job was mapped. Therefore you can have, for instance, one queue with three different utilization targets for group A, B and C or three queues for each of them. At the GLUE level, they will appear the same, via the share concept.

and the ComputingElement is an abstraction of the Batch System,

in the new version, the batch system is associated to the computing resource. I realize that we have to clean up the properties list (moving the batch system specific from computing element to computing resource).

then there should be a direct > association between the ComputingShare and the ComputingElement. Having the ComputingShare linked to the ComputingService will introduce a number of replicated instances of the same ComputingShare on all the ComputingServices which is not really necessary. Attached is the diagram again to refresh your memory on what I think it should look like. Anyway, just my 2 cents..

I think the relationship between a share and the service is needed because you can expose a certain share via a certain service, while another share with another service. You should be able to know which share for which resource is accessible via a certain service interface. We will add detailed information in the doc revision. Cheers, Sergio

Cheers, Gerson

On 6/27/07, *Sergio Andreozzi* < sergio.andreozzi@cnaf.infn.it <mailto:sergio.andreozzi@cnaf.infn.it>> wrote:

Hi everybody,

we have just uploaded a new draft of the GLUE 2.0 specification.

Here are the main changes:

- clarify difference between computing resource and computing element - from Gerson Galang use case: single computing service in front of two different batch systems - general clean-up - inclusion of first UML Class diagram for Storage Element (description to be added) - added activity entity - promoted share entity as a main concept

you can find it in the draft section of GLUE WG document repository: http://forge.ogf.org/sf/docman/do/listDocuments/projects.glue-wg/docman.root... <http://forge.ogf.org/sf/docman/do/listDocuments/projects.glue-wg/docman.root.drafts>

we plan to provide a preview of the new changes in the tomorrow call of the OGSA Resource Management Design Team phonecall: http://www.google.com/calendar/event?eid=N25vaWg5MjQ4NTRzOWJpdTU0c3VwMWZzcmMgb2dzYS53Z0Bt&ctz=America/Chicago <http://www.google.com/calendar/event?eid=N25vaWg5MjQ4NTRzOWJpdTU0c3VwMWZzcmMgb2dzYS53Z0Bt&ctz=America/Chicago>

(we apologize for the short-term advise)

We will set up a phonecall next week for the GLUE WG. Comments/questions are always welcome.

Best regards,

Sergio and Balazs

-- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi <http://www.cnaf.infn.it/%7Eandreozzi> _______________________________________________ glue-wg mailing list glue-wg@ogf.org <mailto:glue-wg@ogf.org> http://www.ogf.org/mailman/listinfo/glue-wg <http://www.ogf.org/mailman/listinfo/glue-wg>

------------------------------------------------------------------------

-- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

Hi, I still have reservations about the resource, service, site etc entities. The share expresses the relationship between resource and service. I don't think we need "element" any more.

From the point of view of service discovery we need to find a service which has a share with a policy expressing that a particular VO has some resources. Is all VO specific policy in the share?

If we get rid of element both services and resources might need a relationship to a site - in which case we should try to define precisely what that relationship means. It may be different for a resource and a service Should I presume that a Computing service is a service (inheritance). If this is the case we need to think at some stage just how this will be realised. Steve

Hi Steve, I completely agree. I was hoping that the reference model group would let us know what the resource, service, site etc. were and the relationship between them. If they do not do this for use we will just have to define what we think they are. Laurence Fisher, SM (Steve) wrote:

Hi,

I still have reservations about the resource, service, site etc entities.

The share expresses the relationship between resource and service. I don't think we need "element" any more.

...

From the point of view of service discovery we need to find a service which has a share with a policy expressing that a particular VO has some resources. Is all VO specific policy in the share?

If we get rid of element both services and resources might need a relationship to a site - in which case we should try to define precisely what that relationship means. It may be different for a resource and a service

Should I presume that a Computing service is a service (inheritance). If this is the case we need to think at some stage just how this will be realised.

Steve _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg

glue-wg-bounces@ogf.org

[mailto:glue-wg-bounces@ogf.org] On Behalf Of Balazs Konya said: The computing element does not represent an LRMS any longer, the LRMS specific info was moved to the computing resource entity.

I haven't yet read the draft, but my immediate reaction is that that sounds a bit odd. Conceptually the batch system is not the same as the hardware/cluster, so can they really be merged? I think one of the problems we've had with the 1.x schema is that the LRMS is not represented explicitly but merged into the service (CE) info; I'm not sure if merging it with the cluster instead is any better. Is there a reason not to represent the LRMS as a primary entity? Stephen