- glue-wg - lists.ogf.org

json rendering & public comment
by Warren Smith 01 Dec '14

01 Dec '14

Hi all, We think the JSON rendering document is ready for public comment. We believe we've addressed everything that has been brought up in the working group discussions. We'd like to get any last comments from you and there will be a vote on November 25 about whether the document is ready for public comment. There will be a working group meeting on the 25th where you can vote. If you can't attend that meeting, I suggest you vote by emailing the working group list on or before the 25th. The rendering document is available in http://redmine.ogf.org/dmsf/glue-wg?folder_id=6593. It appears to be publicly viewable, but if you have any problems seeing it, let me know. If you'd like to see the schema outside of the document or see some examples, you will find those at https://github.com/OGF-GLUE/JSON<https://github.com/OGF-GLUE/JSON/tree/master/schema>. Warren

1 1

GLUE v 2.0 -- Reference Realization to LDAP Schema -- submitted for public comment
by Navarro, John-Paul F. 25 Nov '14

25 Nov '14

Greetings GLUE WG, Per our most recent meeting. I performed a final review of our LDAP rendering recommendation, applied some outstanding corrections, and uploaded a new version to redmine: http://redmine.ogf.org/dmsf/glue-wg?folder_id=14 Our recommendation has not been submitted to the OGF Editor to release for public comment: http://redmine.ogf.org/issues/242 Please reply if I missed any proposed changes so that we can apply them along with other public comment feedback. Thanks, JP

3 4

Fwd: [Editor - document #242] (initial review) GLUE v. 2.0 – Reference Realisation to LDAP Schema
by Navarro, John-Paul F. 24 Nov '14

24 Nov '14

Begin forwarded message: From: <redmine(a)ogf.org<mailto:redmine@ogf.org>> Date: November 23, 2014 9:57:13 PM CST To: undisclosed-recipients:; Subject: [Editor - document #242] (initial review) GLUE v. 2.0 – Reference Realisation to LDAP Schema Issue #242 has been updated by Greg Newby. Status changed from submitted to initial review Assignee set to Andre Merzky Dear John-Paul et al., Thanks for this submission. I have performed the initial Editor review, and am now submitting it for steering group review prior to 60-day public comment. I appreciate your group's efforts for this important submission. I noted your request for publishing the schema. This is no problem to accompany the publication. It is part of our standard procedure to do so. Greg Newby ---------------------------------------- document #242: GLUE v. 2.0 – Reference Realisation to LDAP Schema https://redmine.ogf.org/issues/242#change-653 Author: John-Paul Navarro Status: initial review Priority: Normal Assignee: Andre Merzky Category: Target version: Document Type: Proposed Recommendation This document provides information to the Grid community regarding the LDAP Schema realisation of the GLUE information model (v.2.0). Distribution is unlimited. This implementation is derived from the proposed recommendation GFD.147 “GLUE Specification v. 2.0”. -- You have received this notification because you have either subscribed to it, or are involved in its topic. To change your notification preferences, please click here: http://redmine.ogf.org/my/account

1 0

GLUE WG teleconference, Tuesday, November 11, 2014
by Navarro, John-Paul F. 17 Nov '14

17 Nov '14

Greetings GLUE WG, Our next GLUE WG teleconference will be: : Tuesday, November 11, 2014 : 15:30-17:00 Central Europe, 8:30-10:00 AM US Central We will try this teleconference and screen sharing tool: : Web: https://meet.illinois.edu/herrio/V57YV10Q : --> Cancel login dialog, click guest "Sign in here instead", enter name, click "Join the meeting" : Phone: 1-888-983-3631, International 1-217-332-6338 or 1-312-994-8410 : Conference ID: 6759150 As a fall back we also have: : Web: https://webconf.vc.dfn.de/ogf-glue-wg/ (Adobe Connect) : Login as Guest using your real name Meeting materials folder: : http://redmine.ogf.org/dmsf/glue-wg?folder_id=6588 Proposed agenda: 1) LDAP rendering: assess final wg comments and votes and perhaps forward for public comment Previous: > ACTION 1: JP/Shiraz will call for a working group e-mail vote by July 25 to release LDAP rendering document for public comment. Changes should be submitted as change tracked word updates. > NOTE: Given that the call for vote will not go out till July 23, WG chairs will extend the vote thru July 31st. Discuss status. 2) Enumerations: approve enumerations process document Previous: > We discussed managing separate enumeration files for each enumeration and distributing a shell script to download and concatenate all of them. This will eliminate the overhead of having to maintained a merged file. > Andrew (BES/JSDL) will submit some requested enumerations. Will also submit a request for a new enumeration type coprocessor that we will probably want to include in GlUE 2.1. He wants us to figure out what entity it belongs in within the abstract information model. > Discussed requesting for volunteers thru e-mail list to work on missing enumerations. 3) Cloud Extensions: compare benefits and disadvantages of both approaches Previous: > ACTION 1: Shiraz/JP will call for an e-mail vote on using GLUE 2.1 for interoperable clouds. > ACTION 2: Salvatore will include new Horizon 2020 requirements in the draft 2.1 specification. > ACTION 3: Salvatore will call for an e-mail vote to approve GLUE 2.1 for release for public comment, and request for non-disruptive additions/corrections to be applied before releasing for public comment. > We plan to release GLUE 2.1 with cloud support for public comment around December and (possible) OGF 43 in London. > Discussed whether XSEDE produce a 2.0 community profile? Opinions: fine either way. Perhaps a community practice isn't necessary if XSEDE's implementation is public (which it will be). Discuss status. 4) JSON: continue rendering discussions, discuss next steps. Previous: > ACTION 1: Warren will cleanup document and schema (including dates) and send draft to working group for review and e-mail vote on releasing for public comment. > If working group approves release for public comment: > ACTION 2: Shiraz will export draft to word, enable change tracking, and apply OGF formatting for release for public comment. Public comment announcement will include details of existing and planned implementations. > Discussed creating a wiki page with implementor details pointing to github, mentioning relevant tools, and other guidelines to help implementors. > Agreed to publish to schema.ogf.org, for example: http://schemas.ogf.org/glue/2013/05/spec_2.0_r1/Activity.json > The schema path date will be the month of release for public comment. > In appendix where JSON schema documents are included, precede each schema document with the URL to the above schema.ogf.org publishing location. 5) Future meetings In 2 weeks? December 12 morning in London Regards, JP and Shiraz

5 10

Publishing LDAP and JSON schemas
by Navarro, John-Paul F. 14 Nov '14

14 Nov '14

We've been given a "preliminary" green light to publish LDAP and JSON schemas under: http://schemas.ogf.org/glue/ We should get a final OK after review from more OGF leaders. JP

1 0

GLUE WG teleconference, Tuesday, November 11 availability
by Navarro, John-Paul F. 10 Nov '14

10 Nov '14

Greetings GLUE WG, It has been several months since we've had a teleconference. We propose that our next GLUE WG teleconference be: : Tuesday, November 11, 2014 : 15:30-17:00 Central Europe, 8:30-10:00 AM US Central If you are a recent contributor to the LDAP rendering, Enumerations work, Cloud extensions, or JSON rendering, please reply by Friday November 7 to confirm your availability November 11. We will confirm the meeting and send out an agenda if enough participants are available. Regards, JP and Shiraz

6 5

Off on holiday
by Paul Millar 30 Sep '14

30 Sep '14

Hi all, Just a quick email to say I'm currently off on holiday this week and will be spending the first half of next week away and quite busy with an "All Hands" meeting; so I'll be unlikely to have time to reply before a Thursday next week. Cheers, Paul.

1 0

Fwd: Re: New attribute for GLUE 2.1: StorageShare.ViewID
by Paul Millar 29 Sep '14

29 Sep '14

Hi all, Sorry, my email client decided to sent the reply directly to Maria, so I'm forwarding it here. -------- Forwarded Message -------- Hi Maria, I started off replying generally, rather than point-for-point, but have included some specific points where it makes sense. Yes, dCache instances would move to GLUE 2.1 info-providers, but I would hope to do that anyway. > Do you mean SRM shares could overlap with Physical Shares or do > you mean that SRM shares overlap among themselves and the same > with Physical Shares? I mean that, for dCache: a. an SRM share do not overlap with any other SRM share. b. a Physical share do not overlap with any other physical share. c. a Physical share may overlap with a SRM share. Statement b. isn't completely true currently (as expressed by the SharingID), but I aim to fix that soon. > In any case, if only Physical Shares are intended to be used > for installed capacity, this should be the ones used by > sites who may want to rely on the BDII for installed > capacities, right? Yes, that's exactly right! The problem is GLUE 2.0 has no way for me to say "these shares are different from those ones", or "these shares are the ones to use for storage accounting". The ViewID is aimed exactly at fixing this: I give all the physical shares the same ViewID ("physical" say) and all the SRM shares the same ViewID ("srm-reservations", say) and then it's easy to select the Physical shares. > What is then published in GLUE2StorageServiceCapacity? The total > of Physical Shares? Yes. > But who has asked for this? My understanding is that nobody > is interested on relying on the BDII for this. I had to smile inwardly here ... Yes, there was an effort, starting around five years ago, in precisely this direction: https://twiki.cern.ch/twiki/pub/LCG/WLCGCommonComputingReadinessChallenges/… "The goal of this document is to detail how to use the Glue Schema version 1.3 in order to publish information to provide the WLCG management with a view of the total installed capacity and resource usage by the VOs at sites. This information can also be used by VO operations and management in order to monitor the VO usage of the resource" Myself (and others) invested considerable time in trying to provide these numbers with GLUE 1.3. GLUE 2.0 was developed with this use-case in mind, albeit (from memory) not extensively reviewed. > [...] I´m not sure is a use case we would like to address. It seems at least one site wishes to make use of these numbers and to automate the process. I don't think we should give up, just because the problem isn't solved yet. > I made a comparison in February between WLCG Accounting reports > and what the BDII and REBUS were publishing in terms of installed > capacities. And I think there was no single match for any T1: > http://wlcg-mon.cern.ch/dashboard/request.py/siteview#currentView=WLCG+Acco… I believe there are many factors influencing such dependencies; however, this would suggest a need for more automation, not less. Such dependencies should be investigated and understood. Yes, more work is needed, investigations, etc; however, we have to start somewhere, so I gave a concrete proposal so people have something they can understand: a straw-man they can hack away at. Cheers, Paul.

3 8

new servcie types
by david.meredith＠stfc.ac.uk 26 Sep '14

26 Sep '14

Hi all, GOCDB has added a number of new service types that could be added to the glue2 enum list: com.schedmd.SlurmClient, eu.unity-idm.Unity, eu.unicore.UnicorePortal, eu.egi.egrant Details copied below and at: https://ggus.eu/?mode=ticket_info&ticket_id=108465 Can these be reviewed and added? Thanks David 1. name of service: com.schedmd.SlurmClient 2. high-level description of the service functionality: SLURM (Simple Linux Utility for Resource Management) is an open-source resource manager designed for Linux clusters of all sizes. Machine flagged this type is hosting software to submit jobs to SLURM. http://slurm.schedmd.com/ 3. project/community/organization maintaining the software: open-source 4. scope of deployment (number of instances of the service currently deployed and by which organizations): ICM (Poland) site is using it, possibly more in EGI infrastructure 1. name of service: eu.unity-idm.Unity 2. high-level description of the service functionality: Unity is a complete solution for identity, federation and inter-federation management. Or, looking from a different perspective, it is an extremely flexible authentication service. (http://www.unity-idm.eu) It replaces UVOS service for UNICORE. Possibly each NGI supporting UNICORE mware should deploy one instance. 3. project/community/organization maintaining the software: open-source 4. scope of deployment (number of instances of the service currently deployed and by which organizations): ICM installation for the Polish NGI with redundant installations in future. 1. name of service: eu.unicore.UnicorePortal 2. high-level description of the service functionality: UNICORE Portal service allows users to access a UNICORE Grid via the web browser. Service be used by users instead of standalone clients like UCC and URC to access resources and submit jobs. The UNICORE Portal server is available for download at UNICORE site: http://unicore.eu/download/unicore6/. It is possible in the future that each NGI supporting UNICORE middleware will deploy at least one instance. 3. project/community/organization maintaining the software: open-source (UNICORE community) 4. scope of deployment (number of instances of the service currently deployed and by which organizations): ICM installation for the Polish NGI. 1. name of service: eu.egi.egrant 2. high-level description of the service functionality: platform for Resource Allocation management in EGI Infrastructure 3. project/community/organization maintaining the software: egi.eu 4. scope of deployment (number of instances of the service currently deployed and by which organizations): https://e-grant.egi.eu, deployed for EGI by Cyfronet ========================== David Meredith Scientific Computing Dept 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 3

New attribute for GLUE 2.1: StorageShare.ViewID
by Paul Millar 26 Sep '14

26 Sep '14

Hi all, After playing some more with GLUE 2.0 (and getting feedback from someone trying to use it!), there seems to be a missing concept in StorageShare, which I'll call "views". The idea is to allow publishing two (or more) groups of Storage Shares such that, within such a group, the Storage Shares can be non-overlapping but shares from different groups can overlap. Each group of non-overlapping shares provides a different "view" on the storage system. It's likely that the underlying hardware is the same (with the sum of StorageShareCapacity.Total giving the same value), but the different views (different groups of storage shares) would partition this storage differently. Here's a more concrete example: consider a storage service that allows capacity to be reserved but doesn't bind those reservations to particular hardware. This is difficult to publish currently; but, these could be published as two different views: one view shows the hardware, the other shows the reservations. I believe we can add views while remaining backwards compatible with GLUE 2.0 attributes and semantics; in particular, we can keep the semantics of SharingID unmodified for existing publishers. Here's the proposal: Attribute: ViewID Type: LocalID_t Mult: 0..1 ("optional") Unit: <none> Description: A local identifier that groups together similar Storage Shares. Two shares are part of the same view if and only if both do not publish a ViewID or both publish the same ViewID value. Two Storage Shares that are part of the same view and have either distinct SharingID values or the same "dedicated" SharingID value are non-overlapping, otherwise they may overlap. Since the attribute is optional, existing publishers will continue to work, but will refrain from publishing a ViewID attribute. Since not publishing ViewID places the Storage Share objects in the same view, the GLUE 2.0 SharingID semantics is preserved. Cheers, Paul.

3 7