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''.
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.
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.