Subsections

D. Information Schema

This appendix describes two major parts of the EDG schema-the GLUE schema and the Service and ServiceStatus tables. Note that in addition to the fields shown here there is a pair of fields appended to each of the R-GMA tables: the ``MeasurementDate'' and ``MeasurementTime''.

D.1 GLUE

Most of the published information conforms to the GLUE schemahttp://www.cnaf.infn.it/ sergio/datatag/glue/ version 1.1. EDG has defined a mapping from the LDAP version of this GLUE schema to a relational schema for R-GMA. This is in three parts for the CEhttp://hepunx.rl.ac.uk/edg/wp3/documentation/doc/schemas/Glue-CE.html, the SEhttp://hepunx.rl.ac.uk/edg/wp3/documentation/doc/schemas/Glue-SE.html and the CESEBindhttp://hepunx.rl.ac.uk/edg/wp3/documentation/doc/schemas/Glue-CESEBind.html.

The GLUE schema is represented by a UML diagram to describe the relationships between the different objects.

If we consider the example of the GlueCE, we see in the LDAP schema:

objectclass ( 1.3.6.1.4.1.8005.100.2.1.1
    NAME        'GlueCE'
    DESC        'Info for Computing Element service'
    SUP         'GlueCETop'
    STRUCTURAL
    MUST        (GlueCEUniqueID)
    MAY         (GlueCEName $ GlueCEHostingCluster))

but there are also other classes with a 1:1 relationship with the ``GlueCE'', such as ``GlueCEInfo'':

objectclass ( 1.3.6.1.4.1.8005.100.2.1.2
    NAME        'GlueCEInfo'
    DESC        'General info for the Queue associated to the CE'
    SUP         'GlueCETop'
    AUXILIARY
    MAY         (GlueCEInfoTotalCPUs $ GlueCEInfoLRMSType $ GlueCEInfoLRMSVersion 
               $ GlueCEInfoGRAMVersion $ GlueCEInfoHostName $ GlueCEInfoGatekeeperPort) )

and ``GlueCEState'':

objectclass ( 1.3.6.1.4.1.8005.100.2.1.3
    NAME        'GlueCEState'
    DESC        'CE State info'
    SUP         'GlueCETop'
    AUXILIARY
    MAY         (GlueCEStateRunningJobs $ GlueCEStateWaitingJobs $ GlueCEStateTotalJobs 
               $ GlueCEStateStatus $ GlueCEStateWorstResponseTime $ GlueCEStateEstimatedResponseTime 
               $ GlueCEStateFreeCpus) )

The only attribute which is compulsory (with the MUST keyword) is the ``GlueCEUniqueID'' which is defined as:

attributetype ( 1.3.6.1.4.1.8005.100.2.2.1.1
    NAME        'GlueCEUniqueID'
    DESC        'A CE Unique ID'
    EQUALITY    caseIgnoreIA5Match
    SUBSTR      caseIgnoreIA5SubstringsMatch
    SYNTAX      1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE)

You will note the presence of the keyword SINGLE-VALUE indicating that this attribute may only appear once in an object.

Now take a look at the GlueCE table:

UniqueID VARCHAR(128) A CE Unique ID
Name VARCHAR(255) name of this CE could be the name of the local queue associated with it
GlueClusterUniqueID VARCHAR(100) Relates to GlueCluster
TotalCPUs INT Number of CPUs available to the queue
LRMSType VARCHAR(255) Name of local resource management system
LRMSVersion VARCHAR(255) Version of local resource management system
GRAMVersion VARCHAR(255) The GRAM version
HostName VARCHAR(128) Fully qualified hostname for host where gatekeeper runs
GatekeeperPort VARCHAR(128) Port number for the gatekeeper
RunningJobs INT Number of jobs in a running state
WaitingJobs INT Number of jobs that are in a state different than running
TotalJobs INT Number of jobs in the CE
Status VARCHAR(255) States a queue can be in
WorstResponseTime INT Worst time between job submission till when job starts its execution
EstimatedResponseTime INT Estimated time between job submission till when job starts its execution
FreeCpus INT Number of free CPUs available to a scheduler
Priority INT Info about the Queue Priority
MaxRunningJobs INT The maximum number of jobs allowed to be running
MaxTotalJobs INT The maximum allowed number of jobs in the queue
MaxCPUTime INT The maximum CPU time allowed for jobs submitted to the CE in mins
MaxWallClockTime INT The maximum wall clock time allowed for jobs submitted to the CE in mins
InformationServiceURL VARCHAR(128) URL of the GRIS

The table name is identical to the main LDAP objectclass (in this case ``GlueCE'') and the attributes which must be globally unique in LDAP are taken from the LDAP names but without the prefix of the LDAP objectclass. So ``GlueCEUniqueID'' becomes simply ``UniqueID''. It is shown bold as it is the primary key of the table. The next field is ``Name'' (derived from ``GlueCEName'').

The next field would have been derived from the LDAP attribute ``GlueCEHostingCluster'', however this attribute is deprecated so we skip over it.

The next field is ``GlueClusterUniqueID''. This is the standard way we have to chosen to express relationships by means of a foreign key. This is constructed by taking the name of the related table (``GlueCluster'') and appending the name of the primary key of that table - which in this case is also ``UniqueID'' as attributes are local to a table and not global.

The next bunch of attributes is derived from those of the object classes ``GlueCEInfo'' and ``GlueCEState'' and ``GlueCEPolicy'' (not shown above).

Finally we have the LDAP object class which has one compulsory attribute - but it is not single valued:

attributetype ( 1.3.6.1.4.1.8005.100.2.2.5.1
    NAME        'GlueCEAccessControlBaseRule'
    DESC        'The rule that grant/deny access of this service'
    EQUALITY    caseIgnoreIA5Match
    SUBSTR      caseIgnoreIA5SubstringsMatch
    SYNTAX      1.3.6.1.4.1.1466.115.121.1.26)

objectclass ( 1.3.6.1.4.1.8005.100.2.1.5
    NAME        'GlueCEAccessControlBase'
    DESC        'Info of a VO which users are allowed to access the CE'
    SUP         'GlueCETop'
    AUXILIARY
    MUST        (GlueCEAccessControlBaseRule) )

So a GlueCE may have many values of ``GlueCEAccessControlBaseRule''. This problem of repeated attributes is handled in the normal way in the relational model by defining an extra table ``GlueCEAccessControlBaseRule''

GlueCEUniqueID VARCHAR(128) Relates users to CE
Value VARCHAR(128) The rule that grant/deny access of this service

This table name is identical to that of the LDAP attribute. The value of the quantity is called ``Value'' and in each case there is a foreign key back to the object to which it is related. In this case this is the ``UniqueID'' within the table ``GlueCE'' so it is ``GlueCEUniqeID''. Finally note that to identify a row uniquely within this table requires both attributes - so the primary key is a pair of fields.

Looking again at the relational schema you will see the type of each attribute and a comment.

D.2 Service and ServiceStatus

The Service information is meant to represent what services should exists and the ServiceStatus their current status. The tables are defined in mischttp://hepunx.rl.ac.uk/edg/wp3/documentation/doc/schemas/misc.html and look like:

Service
URI VARCHAR(255) URI to contact the service
VO VARCHAR(50) Where info should be published - or an empty string to indicate all
type VARCHAR(50) Type of service (e.g. EDGResourceBroker)
emailContact VARCHAR(50) The e-mail of a human being to complain to
site VARCHAR(50) Domain name of site hosting the service
secure VARCHAR(1) "y" or "n" - indicates whether or not this is a secure service
majorVersion INT Version of protocol not implementation
minorVersion INT Version of protocol not implementation
patchVersion INT Version of protocol not implementation

ServiceStatus
URI VARCHAR(255) URI to contact the service
status INT status code. 0 means the service is up.
message VARCHAR(255) Message corresponding to status code

Rows are published to the Service table around once an hour by a cron job. This shows which services ought to exist. Information system code checks the published services periodically and publishes their status in the ServiceStatus table.


http://marianne.in2p3.fr