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@stfc.ac.uk Skype name: davidismeredith -- Scanned by iCritical.
Hi David, In principal, adding new services isn't a problem. On 23/09/14 14:49, david.meredith@stfc.ac.uk wrote:
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/
However, this one looks wrong. A service is normally distinguished by having an endpoint through which a client can interact with it. For this reason, Service objects are normally servers, not clients. What you describe sounds like client software for interacting with SLURM: i.e., the software installed on some machines that lets one submit jobs into a SURLM-managed batch system. Would this service describe a machine that a user can log into somehow (ssh?) and, once logged in, can submit jobs via SLURM client? If so, it sounds a bit like a EGI UI machine: how do we publish these currently?
1. name of service: eu.unity-idm.Unity 1. name of service: eu.unicore.UnicorePortal 1. name of service: eu.egi.egrant
These all looks reasonable ... Although I'm sure we can have the discussion about which level of granularity makes sense for Type --- or if it makes sense having Service.Type at all :-) Cheers, Paul.
Paul Millar [mailto:paul.millar@desy.de] said:
A service is normally distinguished by having an endpoint through which a client can interact with it. For this reason, Service objects are normally servers, not clients. What you describe sounds like client software for interacting with SLURM: i.e., the software installed on some machines that lets one submit jobs into a SURLM-managed batch system.
Yes, I thought the same. The GOC DB has some things which are just property tags, which don't really correspond to services in the glue sense, and this may be one of them.
If so, it sounds a bit like a EGI UI machine: how do we publish these currently?
I don't think UIs are defined, but VO boxes are and they are somewhat similar. However, those are machines which provide access to a bundle of client software and other things (e.g. CAs and CRLs), not just a single client. Stephen -- Scanned by iCritical.
Hi David, all I am very busy in this time of the year so I will come back to this very late in time, sorry about it. In principle I agree with the comments Paul and Stephen expressed. Cheers, Florido On 2014-09-24 13:36, stephen.burke@stfc.ac.uk wrote:
Paul Millar [mailto:paul.millar@desy.de] said:
A service is normally distinguished by having an endpoint through which a client can interact with it. For this reason, Service objects are normally servers, not clients. What you describe sounds like client software for interacting with SLURM: i.e., the software installed on some machines that lets one submit jobs into a SURLM-managed batch system.
Yes, I thought the same. The GOC DB has some things which are just property tags, which don't really correspond to services in the glue sense, and this may be one of them.
If so, it sounds a bit like a EGI UI machine: how do we publish these currently?
I don't think UIs are defined, but VO boxes are and they are somewhat similar. However, those are machines which provide access to a bundle of client software and other things (e.g. CAs and CRLs), not just a single client.
Stephen
-- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus B, Rum B313 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
participants (4)
-
david.meredith＠stfc.ac.uk -
Florido Paganelli -
Paul Millar -
stephen.burke＠stfc.ac.uk