Re: [glue-wg] Information has been added
Hi Laurence, At OGF yesterday we agreed to move the GLUE2 XML rendering into public comment within the next few weeks. The XSD, draft GFD and examples are at the link[1] below. A prior question however: Wouldn't it be prudent to consider common names for XML elements and JSON-attributes across the two different renderings, especially the elements/attributes used to define the relationships between entities? Currently, the XML rendering adopts a naming scheme that uses referenced element with the suffix 'ID' (e.g. to reference an endpoint, an entity defines a Ref element called '<EndpointID> ' within its '<Associations>' element). Importantly, as described in section 3.5.1 in the attached doc, we name the Ref element after the referenced element's super-class (if applicable). This is to cater for a well-defined use-case: It allows standard queries to be executed on an instance document regardless of the referenced entity sub-type (I understand that this preference/use-case emerged with use of the LDAP rendering). Conversely however, I see that in your JSON rendering you are specifically naming the attribute after the referenced entity-sub-type specialisation, e.g. 'executionenvironmentforeignkey' rather than 'resourceforeignkey' (resource being the executionenv's abstract super-class). What are your thoughts? Cheers David [1]http://redmine.ogf.org/dmsf/glue-wg?folder_id=31
-----Original Message----- From: Laurence [mailto:Laurence.Field@cern.ch] Sent: 12 March 2013 10:16 To: Stefan Roiser Cc: Maria Alandes Pradillo; infosys-discuss (Grid Information System Discussion List) Subject: Re: Information has been added
Hi Stefan,
I have added the benchmark to the nested view.
http://gsr.cern.ch/apps/gsr/nested/json
This is a little more complicated due to the relationships. The benchmark a sub-object of the execution environment (the hardware). The share is related to an execution environment (executionenvironmentforeignkey).
Laurence
Hi Laurence
Correct, yes this would be useful to have, e.g. would make some page obsolete I'm currently maintaining for LHCb.
cheers
Stefan
On 11 Mar 2013, at 15:17, Laurence <Laurence.Field@cern.ch> wrote:
The power is a property of the computing hardware, not the queue. We can advertise the power of the hardware and indicate what hardware your queue can access.
Laurence
On 03/11/2013 02:52 PM, Stefan Roiser wrote:
Hi,
for what concerns the queues could we add info on the SI2K power of
cheers
Stefan
On 5 Mar 2013, at 16:55, Maria Alandes Pradillo
<Maria.Alandes.Pradillo@cern.ch> wrote:
Hi Laurence,
I would like to write here Andrea's proposal formulated at the end of
We should be able to show the following information in REBUS:
For each site, list the computing endpoints (Endpoint Record view) For each computing endpoint, list the available computing managers (batch system) (Computing Manager view) For each computing
manager,
list the available queues including Max Wallclock time and Max CPU time (Computing Share view)
Display this information per VO and FQAN (This is missing)
Would it be useful for the discussion to create a "Job Submission view" displaying:
Site Name Computing Endpoint Computing Manager Queue Max Wallclock time Max CPU time VO name FQAN
Is it possible?
Thanks! Maria
-----Original Message----- From: Laurence Field Sent: 05 March 2013 16:41 To: infosys-discuss (Grid Information System Discussion List) Subject: Information has been added
I have added the queue name to the Computing Share (mappingqueue) and a new object Computing Manager than contains the
On 03/11/2013 03:19 PM, Stefan Roiser wrote: the queue? This would allow us to calculate the queue length, or maybe this could be done directly on the page in HepSpec06.seconds (i.e. MaxCPU*SI2K*60/250) ? the meeting: productname
and product version. The objects Service Endpoint, Computing Share and Computing Manager all now now a foriegnkey to the Service
http://gsr.cern.ch/apps/gsr/computingmanager/html
All the information is now there for creating the flat json structure.
Laurence
Stefan Roiser, CERN, IT Department, CH-1211 Geneva 23, +41 76 4875334
Stefan Roiser, CERN, IT Department, CH-1211 Geneva 23, +41 76 4875334
-- Scanned by iCritical.
Hi David, In principle, I agree that we need a JSON rendering or rules to serialize the JSON from the XML. I haven't decided whether to be proactive or reactive on this topic but will implement an agreed JSON format when available. However, the goal of the WLCG Registry is to provide the experiments with what they what in whatever format they want it. It can be any custom bespoke format they wish but I will try to steer them towards a good quality GLUE 2.0 rendering where possible. I know that JSON was mentioned in previous GLUE meetings. What is the current state? Laurence On 03/13/2013 10:20 AM, david.meredith@stfc.ac.uk wrote:
Hi Laurence, At OGF yesterday we agreed to move the GLUE2 XML rendering into public comment within the next few weeks. The XSD, draft GFD and examples are at the link[1] below. A prior question however:
Wouldn't it be prudent to consider common names for XML elements and JSON-attributes across the two different renderings, especially the elements/attributes used to define the relationships between entities?
Currently, the XML rendering adopts a naming scheme that uses referenced element with the suffix 'ID' (e.g. to reference an endpoint, an entity defines a Ref element called '<EndpointID> ' within its '<Associations>' element). Importantly, as described in section 3.5.1 in the attached doc, we name the Ref element after the referenced element's super-class (if applicable). This is to cater for a well-defined use-case: It allows standard queries to be executed on an instance document regardless of the referenced entity sub-type (I understand that this preference/use-case emerged with use of the LDAP rendering). Conversely however, I see that in your JSON rendering you are specifically naming the attribute after the referenced entity-sub-type specialisation, e.g. 'executionenvironmentforeignkey' rather than 'resourceforeignkey' (resource being the executionenv's abstract super-class).
What are your thoughts?
Cheers David
[1]http://redmine.ogf.org/dmsf/glue-wg?folder_id=31
-----Original Message----- From: Laurence [mailto:Laurence.Field@cern.ch] Sent: 12 March 2013 10:16 To: Stefan Roiser Cc: Maria Alandes Pradillo; infosys-discuss (Grid Information System Discussion List) Subject: Re: Information has been added
Hi Stefan,
I have added the benchmark to the nested view.
http://gsr.cern.ch/apps/gsr/nested/json
This is a little more complicated due to the relationships. The benchmark a sub-object of the execution environment (the hardware). The share is related to an execution environment (executionenvironmentforeignkey).
Laurence
Hi Laurence
Correct, yes this would be useful to have, e.g. would make some page obsolete I'm currently maintaining for LHCb. cheers
Stefan
On 11 Mar 2013, at 15:17, Laurence <Laurence.Field@cern.ch> wrote:
The power is a property of the computing hardware, not the queue. We can advertise the power of the hardware and indicate what hardware your queue can access. Laurence
On 03/11/2013 02:52 PM, Stefan Roiser wrote:
Hi,
for what concerns the queues could we add info on the SI2K power of
cheers
Stefan
On 5 Mar 2013, at 16:55, Maria Alandes Pradillo <Maria.Alandes.Pradillo@cern.ch> wrote:
Hi Laurence,
I would like to write here Andrea's proposal formulated at the end of
We should be able to show the following information in REBUS:
For each site, list the computing endpoints (Endpoint Record view) For each computing endpoint, list the available computing managers (batch system) (Computing Manager view) For each computing manager, list the available queues including Max Wallclock time and Max CPU time (Computing Share view)
Display this information per VO and FQAN (This is missing)
Would it be useful for the discussion to create a "Job Submission view" displaying: Site Name Computing Endpoint Computing Manager Queue Max Wallclock time Max CPU time VO name FQAN
Is it possible?
Thanks! Maria
> -----Original Message----- > From: Laurence Field > Sent: 05 March 2013 16:41 > To: infosys-discuss (Grid Information System Discussion List) > Subject: Information has been added > > I have added the queue name to the Computing Share (mappingqueue) > and a new object Computing Manager than contains the
On 03/11/2013 03:19 PM, Stefan Roiser wrote: the queue? This would allow us to calculate the queue length, or maybe this could be done directly on the page in HepSpec06.seconds (i.e. MaxCPU*SI2K*60/250) ? the meeting: productname
> and product version. The objects Service Endpoint, Computing Share > and Computing Manager all now now a foriegnkey to the Service > > http://gsr.cern.ch/apps/gsr/computingmanager/html > > All the information is now there for creating the flat json structure. > > Laurence
Stefan Roiser, CERN, IT Department, CH-1211 Geneva 23, +41 76 4875334
Stefan Roiser, CERN, IT Department, CH-1211 Geneva 23, +41 76 4875334
Hi Laurence, I think the JSON effort has recently started - Shiraz and Warren know more. However, I think we were in general agreement that it would be preferable to produce a JSON rendering that closely mirrors the XML rendering since both use a flat structure and so both renderings should use the same naming schemes for similar (consistent) style queries. Hopefully, given the recent work on the XML GFD/XSD, it should be pretty straight forward to now produce a JSON rendering. I think Warren was also interested in producing a JSON schema using http://json-schema.org/ David
-----Original Message----- From: Laurence [mailto:Laurence.Field@cern.ch] Sent: 13 March 2013 10:21 To: Meredith, David (STFC,DL,SC) Cc: Stefan.Roiser@cern.ch; Maria.Alandes.Pradillo@cern.ch; infosys- discuss@cern.ch; glue-wg@ogf.org Subject: Re: Information has been added
Hi David,
In principle, I agree that we need a JSON rendering or rules to serialize the JSON from the XML. I haven't decided whether to be proactive or reactive on this topic but will implement an agreed JSON format when available.
However, the goal of the WLCG Registry is to provide the experiments with what they what in whatever format they want it. It can be any custom bespoke format they wish but I will try to steer them towards a good quality GLUE 2.0 rendering where possible.
I know that JSON was mentioned in previous GLUE meetings. What is the current state?
Laurence
On 03/13/2013 10:20 AM, david.meredith@stfc.ac.uk wrote:
Hi Laurence, At OGF yesterday we agreed to move the GLUE2 XML rendering into public comment within the next few weeks. The XSD, draft GFD and examples are at the link[1] below. A prior question however:
Wouldn't it be prudent to consider common names for XML elements and JSON-attributes across the two different renderings, especially the elements/attributes used to define the relationships between entities?
Currently, the XML rendering adopts a naming scheme that uses referenced element with the suffix 'ID' (e.g. to reference an endpoint, an entity defines a Ref element called '<EndpointID> ' within its '<Associations>' element). Importantly, as described in section 3.5.1 in the attached doc, we name the Ref element after the referenced element's super-class (if applicable). This is to cater for a well-defined use-case: It allows standard queries to be executed on an instance document regardless of the referenced entity sub-type (I understand that this preference/use-case emerged with use of the LDAP rendering). Conversely however, I see that in your JSON rendering you are specifically naming the attribute after the referenced entity-sub-type specialisation, e.g. 'executionenvironmentforeignkey' rather than 'resourceforeignkey' (resource being the executionenv's abstract super-class).
What are your thoughts?
Cheers David
[1]http://redmine.ogf.org/dmsf/glue-wg?folder_id=31
-----Original Message----- From: Laurence [mailto:Laurence.Field@cern.ch] Sent: 12 March 2013 10:16 To: Stefan Roiser Cc: Maria Alandes Pradillo; infosys-discuss (Grid Information System Discussion List) Subject: Re: Information has been added
Hi Stefan,
I have added the benchmark to the nested view.
http://gsr.cern.ch/apps/gsr/nested/json
This is a little more complicated due to the relationships. The benchmark a sub-object of the execution environment (the hardware). The share is related to an execution environment (executionenvironmentforeignkey).
Laurence
Hi Laurence
Correct, yes this would be useful to have, e.g. would make some page obsolete I'm currently maintaining for LHCb. cheers
Stefan
On 11 Mar 2013, at 15:17, Laurence <Laurence.Field@cern.ch> wrote:
The power is a property of the computing hardware, not the queue. We can advertise the power of the hardware and indicate what hardware your queue can access. Laurence
On 03/11/2013 02:52 PM, Stefan Roiser wrote:
Hi,
for what concerns the queues could we add info on the SI2K power of
cheers
Stefan
On 5 Mar 2013, at 16:55, Maria Alandes Pradillo <Maria.Alandes.Pradillo@cern.ch> wrote: > Hi Laurence, > > I would like to write here Andrea's proposal formulated at the > end of
> We should be able to show the following information in REBUS: > > For each site, list the computing endpoints (Endpoint Record > view) For each computing endpoint, list the available computing > managers (batch system) (Computing Manager view) For each > computing manager, > list the available queues including Max Wallclock time and Max > CPU time (Computing Share view) > > Display this information per VO and FQAN (This is missing) > > Would it be useful for the discussion to create a "Job Submission view" displaying: > Site Name > Computing Endpoint > Computing Manager > Queue > Max Wallclock time > Max CPU time > VO name > FQAN > > Is it possible? > > Thanks! > Maria > > > >> -----Original Message----- >> From: Laurence Field >> Sent: 05 March 2013 16:41 >> To: infosys-discuss (Grid Information System Discussion List) >> Subject: Information has been added >> >> I have added the queue name to the Computing Share (mappingqueue) >> and a new object Computing Manager than contains the
On 03/11/2013 03:19 PM, Stefan Roiser wrote: the queue? This would allow us to calculate the queue length, or maybe this could be done directly on the page in HepSpec06.seconds (i.e. MaxCPU*SI2K*60/250) ? the meeting: productname
>> and product version. The objects Service Endpoint, Computing >> Share and Computing Manager all now now a foriegnkey to the >> Service >> >> http://gsr.cern.ch/apps/gsr/computingmanager/html >> >> All the information is now there for creating the flat json structure. >> >> Laurence --- Stefan Roiser, CERN, IT Department, CH-1211 Geneva 23, +41 76 4875334
Stefan Roiser, CERN, IT Department, CH-1211 Geneva 23, +41 76 4875334
-- Scanned by iCritical.
participants (2)
-
david.meredith＠stfc.ac.uk -
Laurence