Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "Adding Custom Service to Information System"

From EGIWiki
Jump to navigation Jump to search
Line 3: Line 3:
= Introduction =
= Introduction =


[[GOCDB | What is GOCDB ?]]
[https://tomtools.cern.ch/confluence/display/IS/Home What is Grid Information System ?]
 
[https://tomtools.cern.ch/confluence/display/IS/InformationProviders Writing Information Providers]
 
[https://documents.egi.eu/document/1324 EGI Profile for the Use of the GLUE 2.0 Information Schema]
 
[http://www.ogf.org/documents/GFD.147.pdf Glue 2 Schema specification (PDF)]


= Process =
= Process =

Revision as of 11:19, 14 March 2013


Introduction

What is Grid Information System ?

Writing Information Providers

EGI Profile for the Use of the GLUE 2.0 Information Schema

Glue 2 Schema specification (PDF)

Process

Service provider Operations
1. Decide on a name for the service type (and endpoint type(s) as appropriate). First see if it fits into one of the existing types; if not, consider whether it should also be aligned with the GOC DB. Names should normally follow a "reverse DNS" style based on a suitable project or organisation name, e.g. org.glite.voms, unless they are "well-known" names like http. For names which are also used in the GOC DB follow the standard procedure for that; otherwise notify the new name(s) to the OGF GLUE working group, or ask EGI to do it.
2. Decide what information to publish. There is a fairly small number of attributes which must be published, but potentially anything can be published although it must be fitted into the GLUE schema structure. Information can be published either in the GLUE 1 or GLUE 2 format or both - GLUE 2 is now recommended. It is potentially possible to extend the GLUE 2 schema, but this would be a major project so it should be avoided if possible.
3. For each piece of information to be published, find a way to collect the information from a script running on a service node. Depending on the nature of the information this may be hard-wired, read from a configuration file, or read dynamically in some way. The information must be collected quickly, within about a second at most, and in a way which is normally guaranteed to succeed. If this is not the case, e.g. if a remote service needs to be contacted, some level of indirection should be used, e.g. a cron job which caches the information in a file to be read by the information provider.
4. Write one or more information providers to output the information according to the schema structure in the LDIF format. For simple services a generic information provider is available as part of the BDII core package; this just requires a configuration file which, for each attribute to be published, specifies a command which writes the value to stdout, so there is no need to understand the schema structure in detail. However, for more complex cases a dedicated provider may be required.
5. Add the BDII core package to the software installed on the service node, install and configure the information providers as necessary and add scripts and/or LDIF files to the relevant directories as described in the BDII documentation. Then start the bdii service. This should result in the information being published from the node.
6. For information to appear in the overall information system ("top-level BDIIs") the service node should be added to the configuration of a site BDII at some suitable Grid site. It is not necessary for the service node to be physically located at that site as long as the site BDII has sufficient access to read the information. If the service is registered in the GOC DB it should be registered under the same site.