A Service entity is formed by a hostname, a hosted service and a URL.
The EGI Configuration Database stores the following information about Service entities (non exhaustive list):
- The fully qualified hostname of the machine
- The hosted service (see
- The URL to reach the entities
- The IP address of the machine
- The machine’s host certificate DN
- A description of the node
As a machine can host many services, there can be many Service entities per machine.
myhost.domain.org runs a CE, an UI and a UnicoreX service. This
will show up in the EGI Configuration Database as 3 Service entities:
|fully qualified hostname||ServiceType|
Note that a single host can also specify multiple services of the same
Manipulating Service entities
Viewing Service entities
There are different pages in GOCDB where Service entities are listed:
- A full Service entities listing page, that shows a listing of all the entities in the database, with controls to page through the listing. The table headers can be clicked to set the ordering.
- Site details page, see GRIDOPS-GOCDB for an example, where all the Service entities belonging to this site are listed
Each Service entity also has its own listing page. By clicking the link to view it, you can see all associated information.
Adding Service entities
Provided you have proper permissions (check the permissions matrix in the Permissions_associated_to_roles section), you can add a Service entity by:
- clicking on the Add a New Service link in the sidebar. Simply select parent site, fill the form and validate.
- By clicking on the Add Service link from a given site’s details page (the link will only appear if you have proper permissions). This will lead you to the same form as above.
Editing Service entities information
The editing process will show you the same form as the adding process. To edit Service entities, simply click the “edit” link on top of the entities' details page.
Removing a Service entity from a site
To delete a Service entity you have permissions on, simply click on the “delete” link on top of the entities’ details page. The interface asks for confirmation before proceeding.
Service Endpoint entities
A Service entity may optionally define Service Endpoint entities which model
network locations for different service functionalities that can’t be described
by the main
For example: The Service entity goc.egi.eu (of ServiceType egi.GOCDB) defines the following Service Endpoint entities:
|Production PI base URL||https://goc.egi.eu/gocdbpi||egi.GOCDB.PI|
Specific Service entities fields and their impact
“beta” flag (t/f)
This indicates whether the Service entity is a beta service or not (part of the staged rollout process).
This is the DN of the host certificate for the service. The format of the DN
follows that defined by the
OGF Interoperable Certificate Profile
which restricts allowed chars to a
PrintableString that does NOT contain
characters that cannot be expressed in printable 7-bit ASCII. For a list of
To supply multiple or alternate DN(s) for a service, for example of the multiple hosts supporting a single Service entity, see strandard extension properties.
“production” flag (t/f)
The Service entities’ Production flag indicates if this service delivers a production quality service to the infrastructure it belongs to (EGI).
- Non-production Service entities can be either Monitored or Not Monitored, depending on the Administrator’s choice.
- Even if this flag is false, the service is still considered part of the EGI and so shows up in the ROD dashboard.
- If true, then the Monitored flag must also be true: All production resources
MUST be monitored (except if the
- This flag is not to be confused with PRODUCTION_STATUS, which is a Site level flag that shows if the site delivers to the production or Test infrastructure.
“monitoring” flag (t/f)
This flag is taken into account by monitoring tools.
- Can only be set to “N” (false) if Production flag is also false.
- If set to “N” the entities won’t be tested.
Usage of PRODUCTION and MONITORED flags for EGI Service entities
All production Service entities MUST be monitored (except for
Production and Monitored
- Operations Dashboard: A failing test of production Service entities generates an alarm in the ROD Operations Dashboard.
- Availability calculation: The Service entities test results are considered for
Availability computation (if and only if the
ServiceTypeassociated to the entities is one of those included in Availability computation)
Non-Production and Monitored: YES/NO
- Availability calculation: If Monitored is set to
YES, the Monitoring Service will test the Service entity, but the test results are ignored by the Availability Computation Engine (ACE).
- Availability calculation: Non-production Service entities are not considered for site availability calculations.
- Operations Dashboard: If Monitored is set
NO, the Service entities is ignored by the Monitoring Service, and no alarms are raised in the Operations Dashboard in case of
- Monitoring tests for non-production Service entities generate alarms into the
ROD Operations Dashboard in case of
CRITICALfailure of the test. These alarms are visible in the Operations Dashboard and are tagged as “non production”.