This page is meant to keep track of the status of the infosystem as per November 2011. The investigation is carried by Florido and Balazs. The page is updated regularily as we made progress, so please check history.

Schema

The infosys startup script /etc/init.d/grid-infosys is rensponsible to gather the schema locations and feed them to the infoproviders.

Lines:

This table shows a summary of the schema status.

Schema name	rendering	Files	Package information	shipped versions
nordugrid	ldap	/usr/share/arc/ldap-schema/nordugrid.schema	nordugrid-arc-aris	we have no schema version. We'll put the last update date
Glue 1.X	ldap	/etc/ldap/schema/Glue-CE.schema /etc/ldap/schema/Glue-CESEBind.schema /etc/ldap/schema/Glue-CORE.schema /etc/ldap/schema/Glue-MDS.schema /etc/ldap/schema/Glue-SE.schema	in EMI and EPEL: glue-schema-2.0.8.noarch.rpm in Ubuntu/Debian official repos: glue-schema_2.0.6-1_all.deb	this refers to version 2.0.8 of the package. Glue-CE.schema - v.1.3 rev 1.1 2007/01/18 Glue-CESEBind.schema - v.1.2 rev 1.8 2008/12/11 Glue-CORE.schema - v.1.2 rev 1.1 2007/01/18 Glue-MDS.schema - no version. Defines the root of the BDII three, but I din't find any call to this in our scripts. Glue-SE.schema - v.1.2 rev 1.2 2007/05/31
GLUE2	ldap	/etc/ldap/schema/GLUE20.schema	in EMI and EPEL: glue-schema-2.0.8-1.el5.noarch.rpm in Ubuntu/Debian official repos: glue-schema-2.0.6.deb	no version information on the rendering not in sync with github. We need a proper release numbering for rendering versions otherwise is always about making diffs
GLUE2	XML	The XML structure is defined by the module `GLUE2xmlPrinter.pm`	No package.	current declared: 'xmlns' => "http://schemas.ogf.org/glue/2009/03/spec/2/0", 'xmlns:xsi' => "http://www.w3.org/2001/XMLSchema-instance", 'xsi:schemaLocation' => "http://schemas.ogf.org/glue/2009/03/spec/2/0 pathto/GLUE2.xsd" for github april 2011 version, code should be: 'xmlns' => "http://schemas.ogf.org/glue/2009/03/spec_2.0_r1", 'xmlns:xsi' => "http://www.w3.org/2001/XMLSchema-instance", 'xsi:schemaLocation' => "https://raw.github.com/OGF-GLUE/XSD/master/schema/GLUE2.xsd"
BDII	ldap	grid-infosys searches in the following locations: "/etc/bdii/BDII.schema" "${bdii_location}/etc/BDII.schema" "${ARC_LOCATION}/share/arc/ldap-schema/BDII.schema" On all the deployments I have, it is only in "/etc/bdii/BDII.schema"	EMI, maintainer Lawrence bdii-5.2.3-1.el5.noarch in EMI-1-base OLD bdii-5.2.5-2.el5.noarch in EMI-1-updates LATEST Maintainer is Mattias for all the following EPEL: bdii-5.2.5-1.el5.noarch LATEST Debian6 in official stable repos: bdii_5.1.7-1_all.deb OLD Ubuntu, in the Universe official repo * maverick (net): 5.1.7-1: OLD * natty (net): 5.1.9-1: OLD * oneiric (net): 5.2.3-2: OLD * precise (net): 5.2.5-2: LATEST	schema carries no version information

Tasks

[ON HOLD] Nordugrid schema Delayed after GLUE2 completion
- check completeness of information, what is published and what not for ng schema (check the tests I did)
- introduce versioning
- check documentation if is in sync with the schema file
- problem arised while playing with integration tasks placing nordugrid schema in a pure bdii config generates errors on some fields. This is probably what Balasz and Mattias meant by incompatibility. Needs further investigation, delayed by now.

GLUE2 LDAP schema
- [ONGOING] document GLUE2 Tasks delayed after GLUE2 ( reminder: old backends doc has some stuff)

[ONGOING] XML schema: there is no latest EMI. Maybe a open a ggus ticket?

BDII schema
- [DONE] nothing in these stats is related to our perl infoproviders execution time. It only relates to their output. Play with the infosys to understand how useful are and how they are related to scripts execution. What is being measured?
  - see https://twiki.cern.ch/twiki/bin/view/EGEE/BDII#Monitoring_the_BDII_Instance

In particular, the following are interesting:

Metric	Description	Comment
FailedDeletes	The number of delete statements which failed	useful to spot publication problems
UpdateTime	total update time in seconds	The total time of running the bdii-update script tasks
DBUpdateTime	The time taken to update the database in seconds	The time it takes to run ldap-add, ldap-modify, ldap-delete against slapd db and run a query for the "shadow"
ReadTime	The time taken to read the LDIF sources in seconds	For some reason this is always 0. We give no static ldifs to BDII. everything is generated by the arc-nordugrid-bdii-ldif metascript and the arc-default.ldif.pl that generates the roots.
ProvidersTime	The time taken to run the information providers in seconds	This is NOT the time our infoproviders run. This is the time it takes to execute the provider script generated by ARC infoproviders.

grid-infosys startup script notes

The grid-infosys script can be divided in 15 conceptual blocks of code. Looking at the code it grow more or less in a disordered manner, making it quite hard to understand by reading it. In the following I'll try to divide the conceptual blocks, give a description of the subroutines, explain the workflow on the start(), stop() and status() functions

Conceptual Blocks

A longer document with line numbers referring to a specific SVN changeset can be found here.

The following is a brief description to get the idea.

INIT INFO preamble
preamble at the beginning of the script indicates how the rc and lsb system must handle the startup script. This information comes as a comment (# in front of it)
INIT and lsb related functions
init and lsb system-specific routines for services startup are sourced here. A few logging functions are set.
Some default variables
Default variables such as this script name and a RETVAL used to contain the exit values are set.
sysconfig (RedHat) or /etc/default (Debian) settings
sysconfig only exists in RedHat based systems. Debian systems have /etc/default instead. The systems don't work the same so the script as to set relevant information here.
Definition of several helper functions
Here the functions debug_echo, error_echo, std_header, printregldif, chech_cwd are defined
set ARC_LOCATION
ARC standard location is configured. This depends on the build, but in most cases is /usr (the ./configure prefix)
Load configuration parser
the arc.conf configuration parser routines are sourced.
set ARC_CONFIG
sets the path to arc.conf
check and fix for an OpenLDAP bug in RHEL4
definition of config_set_default()
the subroutine sets defaults for the infosys REGARDLESS of arc.conf
export pkgdatadir, parses arc.conf
pkgdatadir contains the path to the parser. Then calls configuration parser on arc.conf
Settings for infosys:
1. Parses [common] section, parses [infosys] section
2. Defines check_ownership and get_ldap_user
3. loads some slapd-related values from arc.conf
4. creates log dirs
5. sets ldap user (uses get_ldap_user) sets bdii-related values from arc.conf
6. parses enabled schemas
7. sets some timing for infoprovider updates
8. defines pid files for slapd and bdii-update
9. copes with debian lack of /var/lock/subsys
10. check bdii/slapd runtime dirs permissions (logs, /var/run, /var/tmp)
11. does some checks depending on the old or new infosys scripts (infosys_compat)
12. searches for location of ldap core and glue schemas
13. searches for system LDAP
14. if gris/giis modules are not compiled in LDAP, some variables will be added
15. clears, sets and performs checks for glue1.x
16. sets BDII config file location and exports it; creates giis-fifo
Defines several subroutines.
- create_bdii_conf
  will create bdii.conf file. This is the bdii file that sets bdii related variables: where to get ldifs, what is the user running bdii-update, logfiles...
  
  usually in /var/run/arc/infosys/bdii.conf
- create_arc_slapd_conf
  will create bdii-slapd.conf. This is the slapd configuration file, and will be filled with schema inclusions, slapd module paths, and other parameters (maybe some of those should be rechecked)
  
  usually located in /var/run/arc/bdii/bdii-slapd.conf
- add_info_service
  adds information to slapd configuration created above: references to databases for each root dn.
- create_default_ldif
  will create a perl script that generates part of ldif files
  
  This script generates ldif root structure and adds validfrom and validto stuff
  
  usually located in /var/tmp/arc/bdii/provider/arc-default.ldif.pl
- create_arc_ldif_generator_compat
  creates a perl script that generates ldif trees in compat mode, by running cluster.pl and se.pl
  
  usually located in /var/tmp/arc/bdii/provider/arc-nordugrid-bdii-ldif
- create_arc_ldif_generator
  creates a perl script that generates ldif trees in A-REX infoproviders mode. It waits for A-REX infoproviders to generate data, collects it, and runs se.pl if there is any SE.
  
  usually located in /var/tmp/arc/bdii/provider/arc-nordugrid-bdii-ldif
- create_registration_config_file
  Creates the registration config file
  
  usually located in /var/run/arc/infosys/grid-info-resource-register.conf
- add_index_services
  generates bdii config file information for index services.
  
  uses printregldif and creates/append /var/run/arc/infosys/grid-info-resource-register.conf above.
- create_glue_ldif_generator
  Will create glue1x ldif generator script
  
  usually located in /var/tmp/arc/bdii/provider/arc-glue-bdii-ldif (compat)
  
  usually located in/var/run/arc/infosys/arc-glue-bdii-ldif (A-REX)
- create_directory
  subroutine to create a dir in a smart way. Removesit if exists and checks permissions.
- create_bdii_config_files
  runs the previously defined subroutines to create all the bdii related config files.
  
  It also creates the site-bdii block if the option is present in arc.conf
  
  It calls, in order: create_bdii_conf, create_arc_slapd_conf, create_default_ldif, if compat enabled runs create_arc_ldif_generator_compact and create_arc_ldif_generator, otherwise calls create_arc_ldif_generator (A-REX infoproviders). Creates site-bdii info, then calls create_registration_config_file, add_index_services, add_info_services
- notify_about_bdii
  print some info about where to find bdii logs
- check_clean_status
  check status of the infosys, if unclean shutdown occurred, clean up
defines start(),stop(),status()
main case for the above function and exit RETVAL

Main script workflows

At every call the script always loads everything until point 15).

At point 15 of the above conceptual description, the case loop will capture and executed one of the start(), stop() and status() functions.

start()

check_clean_status
notify_about_bdii
check_cwd
create var/tmp/arc directories with create_directories
create_bdii_config_files
create slapd db directory
create db directory structure in /var/run/arc/bdii/db
create archive directory /var/run/arc/bdii/archive
chown above directories to slapd/bdii user
creates password for slapd db
starts infoindex server
starts slapd
starts bdii-update
starts registration scripts

stop()

check_cwd
stop bdii-udpate
stop slapd
stop infoindex (sends a STOP command to pipe)
clean /var/tmp/arc and /var/run/arc arc dirs

status()

check slapd lockfile/pidfile
check bdii-update lockfile/pidfile

Tasks

[ONGOING] for now, only restarting grid-infosys solves this problem. Maybe a bdii issue? BDII doesn't clean up old IDs, dead objects still there, why?
[NOT DONE] add some logic to validate the tree (validating content of ldif-provider.sh script) before bdii-update starts

Clues: some validation is performed on arc.conf values and on some data gathered by infoproviders. The latter is mostly XML checks.

a dryrun of CEinfo.pl might be the way of doing this, but CEinfo.pl must be run with the same uid,gid as a-rex, or it will generate files that cannot be accessed by the infosys later

[NOT DONE] delayed, must have splitting startup script for local and index startup script. This has become more important as it triggers dependencies.
[NOT DONE] cleanup for BDII4 Note: BDII team has changed directories once again, so this must be done carefully.

ARC Endpoints and Services

See ARC GLUE2 LDAP Tree.

Missing/don't know if needed: Index services
- LDAP EGIIS endpoint/interface

Interface information and jobs

Interface information is stored in controldir job.#.local

one job queried by many interfaces: JobID depends on interface. Infosystem is already aware of which interface the jobs come from.

Attribute completeness

opened a bug for missing glue2 entries : see https://bugzilla.nordugrid.org/cgi-bin/bugzilla/show_bug.cgi?id=2725

Naming Conventions

Local information system

ServiceTypes:

AREX Computing ServiceType: org.nordugrid.execution.arex discontinued. Changed to org.nordugrid.arex

ARIS Information ServiceType: ~~org.nordugrid.information.aris~~ discontinued. ARIS will not be shown as a Service anymore.

ServiceCapability: calculated as the union of endpoints capabilities (must be calculated at runtime)

Endpoints:

AREX GRIDFTP job management interface (formerly ARC0):

InterfaceName: org.nordugrid.gridftpjob

Capability: executionmanagement.jobexecution, executionmanagement.jobmanager, executionmanagement.jobdescription

AREX XBES (a-rex wsrf and eXtended BES interface, formerly ARC1): Note that for backward compatibility we kept the bes thing, a client should check interfaceExtension to know what spefic extension is supported.

InterfaceName: org.ogf.bes

InterfaceExtension: urn:org.nordugrid.xbes (GLUE2 mandates this MUST be a URI)

Capability: executionmanagement.jobexecution, executionmanagement.jobmanager, executionmanagement.jobdescription

AREX EMIES:

Please see EMI-ES specification: https://twiki.cern.ch/twiki/pub/EMI/EmiExecutionService/EMI-ES-Specification_v1.15.odt

ARIS LDAP GLUE2:

InterfaceName: org.nordugrid.ldapglue2