- glue-wg - lists.ogf.org

how to commit to GLUE2 github?
by Florido Paganelli 15 Oct '12

15 Oct '12

Hi all, I was trying to access GLUE2 github area to create the enumerations repositories and create a LDAP experimental branch. Does anyone know how it works to get write access? I don't see anything to request it... Thanks, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project

4 5

Next phone meeting on 04.10
by Shiraz Memon 09 Oct '12

09 Oct '12

Dear WG, Due to other commitments I have to shift our today's phone meeting to Thursday the 04.10. Apologies for this last minute change. Coordinates: * Go to https://webconf.vc.dfn.de/ogf-glue-wg/ and login as guest using your real name * Date: 04.10.2012 * Time: 16:00-17:30 CEST, 15:00-16:30 BST, 10:00 - 11:30 US Eastern Time The agenda items will be: * XML rendering updates and advancements to the flat schema * progress on LDAP rendering document with respect to DIT standardisation * Unified GLUE enumerations and process to update them autonomously * Summary of GLUE session at EGI-TF * Preparation for OGF36 * AOB? As agreed, to allocate more time to the discussions, two 90 min. GLUE-WG sessions have been requested at the OGF36. So far the agenda is bit rough, I will share it shortly on the list and soon it will appear on the conference page. Of course you are most welcome to make any suggestions. Here is a link to the OGF36 schedule: http://www.ogf.org/gf/event_schedule/index.php?event_id=25 Thanks and best regards, Shiraz -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899<tel:%2B49%202461%2061%206899> Fax: +49 2461 61 6656<tel:%2B49%202461%2061%206656> ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unsere app? http://www.fz-juelich.de/app

4 5

EGI TF sessions
by stephen.burke＠stfc.ac.uk 09 Oct '12

09 Oct '12

Hi, These were the GLUE sessions at the TF, I think all slides are now there: https://indico.egi.eu/indico/contributionDisplay.py?contribId=75&confId=1019 https://indico.egi.eu/indico/sessionDisplay.py?sessionId=51&confId=1019#201… David also gave a talk in the operations session: https://indico.egi.eu/indico/contributionDisplay.py?sessionId=39&contribId=… My EGI profile document is here - any comments are welcome: https://documents.egi.eu/document/1324 Stephen -- Scanned by iCritical.

2 2

JSON rendering
by Warren Smith 05 Oct '12

05 Oct '12

Before I forget, I thought I'd send out a couple example documents for the JSON rendering that I'm using for a distributed testbed called FutureGrid. I'm advocating that we switch to JSON for XSEDE, but XSEDE has a fair amount of momentum with XML from TeraGrid and a couple of the new tools we're deploying, so we'll see. Similar to the TeraGrid XML rendering, the style of this rendring is "flat". There are two documents because sensitive information (ComputingActivities that have user names) is placed in a separate document that can be protected while the non-sensitive information is available to anyone in the other document. I think there was at least one other project that created their own JSON rendering. Is mine in the same ballpark as yours? Are there folks interested in defining an official JSON rendering? Warren

3 7

xml rendering discussion
by david.meredith＠stfc.ac.uk 04 Oct '12

04 Oct '12

Hi all, Please find attached a pdf that I hope summarises the flat vs nested XML renderings and their pros/cons. The pdf also includes some other (less important) style choices for the flat rendering (i.e. whether to use Grouping elements, BaseType attributes or both). I have tried to include all recent comments. Cheers, David ========================== David Meredith Scientific Computing Technology eScience Daresbury Laboratory Tel: +44 (0) 1925 603762 Fax: +44 (0) 1925 603100 (Site) Email: david.meredith(a)stfc.ac.uk Skype name: davidismeredith -- Scanned by iCritical.

1 0

flat xml rendering
by david.meredith＠stfc.ac.uk 04 Oct '12

04 Oct '12

Hi all, Following OGF 35 I have produced an updated draft of the XSD: http://tools.ngs.ac.uk/ngstools/glue2proposal/flat.zip This rendering has a 'flat' style and includes the global <Entities> element bag with abstract elements/substitution groups. There are a few choices that still need to be addressed which are highlighted with TODO annotations (please do a search on 'TODO' in glue2_2.xsd). A sample instance document is also provided (glue2_2SampleDoc1.xml). For the purposes of demonstration, there is also a sample XSD (sampleGlue2_2Extension.xsd) that imports the glue2_2.xsd to define new service and endpoint element types. This shows how future profiles could extend the glue XSD in order to define new sub-type specialisations (also see the sample instance doc, sampleGlue2_2ExtensionDoc.xml). I guess the next step is to do another telephone conf to agree/disagree. If possible, i would prefer to do this before spending too much effort on updating the Word doc. Cheers, David ========================== David Meredith Scientific Computing Technology eScience Daresbury Laboratory Tel: +44 (0) 1925 603762 Fax: +44 (0) 1925 603100 (Site) Email: david.meredith(a)stfc.ac.uk Skype name: davidismeredith -- Scanned by iCritical.

4 14

Summary of changes in LDAP GLUE2 rendering as requested in last meeting
by Florido Paganelli 20 Sep '12

20 Sep '12

Dear all, Here is the requested summary for the latest changes in the LDAP Realization draft. (see meeting notes http://redmine.ogf.org/projects/glue-wg/wiki/29_August_2012) We really would like to progress with this document and reach an agreement for the document ready to be submitted to the ogf procedure in one month. The LDAP document was tracked for changes to the purpose of making it easy to check differences between previous versions. Version 6.0: http://redmine.ogf.org/dmsf_files/123?download=264 The document also contains open questions that we would like the group to discuss. These are recorded as comments in the draft. We strongly recommend to go through all the changes and give feedback if some of the changes is questionable. Below we list the major structural modifications: C1) Rewrite of Section 3.7: Directory Information Tree The old document contained a proposed DIT that was incomplete and not followed by any of the actual implementations. We almost completely rewrote the section on DIT, introduced three-level information structuring and provided three detailed pictures that correspond to actual implementation apart from minor proposed changes. This is the section that actually contains most of the changes and should be read. C2) Section 3.5 Datatypes We corrected the datatypes to match the current LDAP schema used by EMI. C3) All over the document: followed the RFC4512 terminology, e.g. renamed "ldap objects" to "ldap entries". The following open questions arised during the review, and we would like the group to discuss them: Q1) Section 3.4, Object Class types and Inheritance Choice of structural/auxiliary should be revised. Seems too restrictive to allow only the first child of the Entity to be structural. For example: ComputingService is not structural. Q2) Section 3.4, Object Class types and Inheritance The strange and complex choice on the LDAP attribute names selected to form DNs is not motivated and explained. We would like to discuss a major simplification that makes implementation straightforward. For example, What is the benefit not to have GLUE2Endpoint instead of GLUE2ComputingEndpointID or GLUE2ServiceID instead of GLUE2StorageServiceID, while all the less important entities such as Benchmark have their own GLUE2BenchmarkID? Q3) Section 3.8, OID assignments The used OID allocation mechanism is not extensible when it comes to adding attributes to entry. Furthermore, the choice is strange, it is not applied consistently and its benefits are unclear. Explaining this in a email is not easy, one really needs to read the section and come back for discussion. Regards, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project

5 9

LDAP tree
by stephen.burke＠stfc.ac.uk 04 Sep '12

04 Sep '12

Hi, I'd like to summarise my views on what aspects of the LDAP DIT should be specified: o The base DN is o=glue. o Extension objects must be immediately below the object they extend (below meaning further from the base DN) because they are logically part of that object. o Service grouping: if there is a Service object, any component objects that relate to it must be somewhere below it in the tree, and no other objects must be there. That means for example that you can remove a Service by deleting the Service object and its subtree. o Site grouping: Services relate to exactly one AdminDomain object which represents the concept of a Grid site (possibly distributed). Similarly to the Service grouping, the tree below an AdminDomain should normally contain all the objects related to it and not objects that relate to other AdminDomains. However, it may be that that can't be an absolute requirement because distributed sites might need a more complex publishing scheme. o Object existence: in general objects are not required to exist in a given server even if references to them exist. For example it may be useful to have a specialised server which only contains some types of object, and an implementation may choose not to publish some types of object at all. However, LDAP does require that all objects whose IDs are used in DNs must exist. This is one argument for not specifying the DIT more than necessary. o Site information: an LDAP server which publishes information for a single site should use a base DN of DomainID=<site-name>,o=glue. That follows naturally from the site grouping principle. o Grid information: an LDAP server which collects information from a range of sites across the Grid should use a base DN of GLUE2GroupID=grid,o=glue. That allows, for example, a single server to provide both site-level and Grid-level information. o Other information: any other information grouping should be published under a base DN of GLUE2GroupID=<group-name>,o=glue, where the group-name is defined by the implementation. o Anything else is free for an implementation to choose. In particular the number of nodes in the tree between any two objects is not defined (other than for Extensions), because it may be convenient to insert grouping objects. I would also like to explain my view on what the LDAP rendering document should and should not specify. Essentially I see it as specifying the LDAP schema and some aspects of the DIT construction as described above. I do not think it should specify anything about a particular implementation technology, notably the BDII, because we want to be free to evolve that technology without breaking compatibility with external clients, by which I mean any software which queries LDAP servers for GLUE 2 information. It also leaves it open to other Grid projects, e.g. OSG or Nordugrid, to develop a different technology which can be interoperable as long as they use the same schema. Stephen -- Scanned by iCritical.

2 2

EGI TF
by stephen.burke＠stfc.ac.uk 31 Aug '12

31 Aug '12

Hi, Details for the Technical Forum: the main info system workshop is at 11 am on Thursday 20th in the Zenith room, and is part of the main operations track so it may get a fairly large audience: https://indico.egi.eu/indico/contributionDisplay.py?contribId=75&confId=1019 In addition there are GOC DB and gstat talks in sessions on operations tools on Wednesday 19th: https://indico.egi.eu/indico/sessionDisplay.py?sessionId=39&confId=1019 I've also asked for a room on the Thursday afternoon: When: Thurs 20 Sep at 16:00 Where: Aquarius Title: GLUE schema tech meeting Event: Closed Meeting INDICO Timetable: Not included I asked for a closed meeting so we don't get too many people, but anyone with an interest can turn up - the room holds 63 (I asked for a smaller room but it was already booked). We don't need to use it if we have nothing to discuss, but 90 minutes in the main session isn't a lot. (NB The conference dinner is on the Thursday evening so we can't go on too long :) If anyone wants to propose any talks or discussion topics let me know. Stephen -- Scanned by iCritical.

1 0

Flat xml schemas are on redmine now
by Shiraz Memon 30 Aug '12

30 Aug '12

Hi David, All, The flat xml schemas can now be found under Documents, on the glue's redmine page. http://redmine.ogf.org/dmsf/glue-wg?folder_id=31 The documents can be versioned and locked to easily track the forthcoming changes. Cheers, Shiraz -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unsere app? http://www.fz-juelich.de/app

1 0