Difference between revisions of "GOCDB/Input System User Documentation"

From EGIWiki
Jump to: navigation, search
m (Adding new services types)
(Changing your accountID)
 
(2 intermediate revisions by the same user not shown)
Line 100: Line 100:
 
Under the following circumstances it is possible to lose access to a GOCDB account that was originally created using a client certificate:  
 
Under the following circumstances it is possible to lose access to a GOCDB account that was originally created using a client certificate:  
 
* If you change your certificate, it is possible that the certificate's distinguished name (DN) has also changed. This is what GOCDB uses to identify your account.  
 
* If you change your certificate, it is possible that the certificate's distinguished name (DN) has also changed. This is what GOCDB uses to identify your account.  
 +
* If you choose to stop using your client certificate to log into GOCDB and istead access GOCDB via the EGI IdP.
 
* If you have an account linked to your certificate but later login via the EGI-IdP route and mistakenly change your accountID from your certDN to the newly assigned ID issued by the EGI IdP.     
 
* If you have an account linked to your certificate but later login via the EGI-IdP route and mistakenly change your accountID from your certDN to the newly assigned ID issued by the EGI IdP.     
  
In either of these situations, it is usually possible to revert and regain access using your certificate by following one of the following procedures:   
+
In these situations, it is usually possible to regain access using to your certificate based account by following one of the following procedures:   
 
   
 
   
 
====If you have a new certificate and have lost access to your account====
 
====If you have a new certificate and have lost access to your account====
Line 113: Line 114:
 
* Specify in the form the DN of your old certificate, and the e-mail address associated to your account.
 
* Specify in the form the DN of your old certificate, and the e-mail address associated to your account.
 
* Upon validation, an e-mail will be sent to the specified address, which has to match the one registered with your account. This is to avoid identity theft. The e-mail contains a validation link.  
 
* Upon validation, an e-mail will be sent to the specified address, which has to match the one registered with your account. This is to avoid identity theft. The e-mail contains a validation link.  
 +
* Click on the validation link or copy/paste in your browser. Once validated, changes are immediate.
 +
 +
====If you choose to stop using a client certificate in favour of the EGI IdP====
 +
NOTE: Following this process will mean you can *only* login to your GOCDB account via EGI Check-In going forward
 +
* Access GOCDB via the EGI IdP
 +
* In the "user status" panel in the sidebar, click on the retrieve an old account link.
 +
* Specify in the form: the DN of your old certificate; and the e-mail address associated to your account.
 +
* Upon validation, an e-mail will be sent to the specified address, which has to match the one registered with your account.
 
* Click on the validation link or copy/paste in your browser. Once validated, changes are immediate.
 
* Click on the validation link or copy/paste in your browser. Once validated, changes are immediate.
  

Latest revision as of 17:16, 11 February 2020

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


GOC DB menu: Home Documentation Index


Contents

Introduction

Scope of this documentation

This user documentation is about the GOCDB5 Input System, which is either:

Other documentation

Version and improvements

This documentation is meant to be useful and accurate. If you think it is not, please send us any improvement suggestions to gocdb-admins_at_mailman.egi.eu

GOCDB version supported in this documentation: 5.3+

Quick Orientation guide

Accessing GOCDB5 input system

To access the web interface, you need an X509 digital certificate installed in your browser, delivered by one of the recognised EU-Grid-PMA Certification Authorities.

  • Obtain a X509 digital certificate
    • Please note, GOCDB does not support single or double quotes in the certificate DN (Distinguished Name).
      • This DN is rejected by GOCDB because of the single quote: /C=UK/O=STFC/OU=SomeOrgUnit/CN=David Mc'Donald
      • This is in accordance with RFC1778 which also disallows single quotes in all Relative Distinguished Name (RDN) components, and the OGF Certificate Authority Working Group (CAOPS) who strongly discourage any type of quote in a certificate DN as specified by their Grid Certificate Profile document.
  • Enter GOCDB5 central web portal at https://goc.egi.eu/portal

You can access the system as soon as you have a recognised X509 certificate, however you will only be able to update information if you register and obtain a role. More information about roles and associated permission is available in the #Users and roles section.

All roles applications need to be validated by parent roles or administrators. Once this is done, you can access/modify relevant information according to the role you have been granted. You can learn more on roles and user accounts by reading the #Users and roles section of this documentation.

How is the information organised?

GOCDB5 supports multiple projects. Each Project groups zero or more NGIs. An NGI groups zero or more Sites. A Site groups zero or more Services. ServiceGroups can also be used to group Services belonging to different Sites. Downtimes are declared over Services. Users have roles over target objects.

  • Projects group child NGI's
  • NGIs group chid Sites
  • Sites group child Services
  • Services group child Downtimes
  • Downtimes and related information
  • Service Groups Group Servies defined across different Sites
  • Users own zero or more Roles
  • Roles link a User to a target entity and a defined role type.


For more details see: https://wiki.egi.eu/w/images/d/d3/GOCDB5_Grid_Topology_Information_System.pdf

Users and roles

Understanding and manipulating user accounts

Authentication

The GOCDB UI attempts to authenticate you in one of two ways (the REST style API applies x509 only):

  • First, by requesting an IGTF accredited user certificate from your browser. If a suitable certificate is detected, you will be asked to confirm selection of your certificate in your browser.
  • Second, if you do not have a user certificate or you hide your certificate from GOCDB (e.g. by starting a new/anonymous private browser session or pressing 'Cancel' when prompted for a certificate), you will be redirected to the EGI Identity Provider Service (IdP) where you can authenticate with your chosen institution (if available). If authentication is successful, you will be re-directed back to GOCDB. Please note, not all logins available in the EGI IdP provide a sufficient level of assurance (LoA) to login to GOCDB (the LoA must be 'Substantial').

Each GOCDB user account is linked to a single account by an ID string - this ID from comes either your Certificate DN or from the EGI IdP service. It is important to note that GOCDB does not perform account-linking - each ID string maps to a separate GOCDB account. Existing users who have already registered an account will be logged into their account, while new users may choose to register a new account.

Registering a new user account

Being authenticated in one of the two ways described above is enough to have read-only access to all the public features of GOCDB. If you need to edit data in GOCDB and request roles, you will need to fill in the registration form.

To Register:

  • Go to the GOCDB web portal
  • In the left sidebar, look out for the User status panel
  • click on the "Register" link
  • fill in the form and validate

Note: If you were registered in GOCDB but are not recognised anymore (e.g. because your certificate DN changed), do not register again! Instead, follow the steps described in the #Changing_your_accountID section

Editing your user account

The editing process is the same as the registration process. To edit your use account, simply follow these steps:

  • click on the "view details" link in the "User Status" panel on the sidebar. you should get a page showing your user account information
  • click on the "edit" link on top of it.

Viewing users

Each user account has its own user details page which is accessible to anyone with a valid certificate.

There is currently no facility for listing all users in the database. List of users that have a role on a given site appears on site details pages (see section about sites). It is also possible to search for a user's account using the search feature on the sidebar.

Deactivating a user account

If you wish to unregister from GOCDB, follow these steps:

  • click on the "view details" link in the "User Status" panel on the sidebar. you should get a page showing your user account information
  • click on the "delete" link on top of it.
  • confirm your choice

Your account will then be deactivated and all your roles revoked.

Changing your accountID

Under the following circumstances it is possible to lose access to a GOCDB account that was originally created using a client certificate:

  • If you change your certificate, it is possible that the certificate's distinguished name (DN) has also changed. This is what GOCDB uses to identify your account.
  • If you choose to stop using your client certificate to log into GOCDB and istead access GOCDB via the EGI IdP.
  • If you have an account linked to your certificate but later login via the EGI-IdP route and mistakenly change your accountID from your certDN to the newly assigned ID issued by the EGI IdP.

In these situations, it is usually possible to regain access using to your certificate based account by following one of the following procedures:

If you have a new certificate and have lost access to your account

  • First install your new certificate in your browser.
  • Go to GOCDB. If you are already logged in, then clear your caches and restart your browser or start a new private browser session.
  • When prompted, select your new certificate but DON'T Register a new account.
  • You should be able to access GOCDB, but since you are authenticated with your new certificate, it is as if you had no user account (you have not registered your new certificate with GOCDB yet).
  • In the "user status" panel in the sidebar, click on the retrieve an old account link.
  • Specify in the form the DN of your old certificate, and the e-mail address associated to your account.
  • Upon validation, an e-mail will be sent to the specified address, which has to match the one registered with your account. This is to avoid identity theft. The e-mail contains a validation link.
  • Click on the validation link or copy/paste in your browser. Once validated, changes are immediate.

If you choose to stop using a client certificate in favour of the EGI IdP

NOTE: Following this process will mean you can *only* login to your GOCDB account via EGI Check-In going forward

  • Access GOCDB via the EGI IdP
  • In the "user status" panel in the sidebar, click on the retrieve an old account link.
  • Specify in the form: the DN of your old certificate; and the e-mail address associated to your account.
  • Upon validation, an e-mail will be sent to the specified address, which has to match the one registered with your account.
  • Click on the validation link or copy/paste in your browser. Once validated, changes are immediate.

If you mistakenly changed your accountID from your certDN to the ID issued from the EGI IdP and have lost access using your certificate

  • Go to GOCDB. If you are already logged in, then clear your caches and restart your browser or start a new private browser session.
  • When prompted, select your certificate you want to reinstate/re-associate with your account - DON'T Register a new account.
  • You should be able to access GOCDB but since you are authenticated with the certificate that is no longer linked to your account, it is as if you had no user account.
  • In the "user status" panel in the sidebar, click on the retrieve an old account link.
  • In the form, specify the DN of your certificate that you want to reinstate, and the e-mail address associated to your account.
  • Upon validation, an e-mail will be sent to the specified address, which has to match the one registered with your account. This is to avoid identity theft. The e-mail contains a validation link.
  • Click on the validation link or copy/paste in your browser. Once validated, changes are immediate.


If for any reason you were unable to complete these steps (e.g. mail confirmations problems) please do not register a new user account, but contact the GOCDB support helpdesk instead.

Understanding and manipulating roles

Roles definition

Registered users with a user account will need at least one role in order to perform any useful tasks.

Role Types

  • A role: Unregistered users
  • B role: Registered users with no role
  • C role: Users with a role at site level (site admin)
  • C' role: Users with a management role at site level (site operations manager, site security officer...)
  • D role: Users with a role at regional level (regional staff support staff, ROD, 1st Line Support)
  • D' role: Users with a management role at regional level (NGI manager or deputy, security officer)
  • E role: Users with a role at project level

The only difference between C and C' users is that:

  • C can NOT approve/reject role requests.
  • C' can only approve/reject role requests for their SITE.

The difference between D and D' users is that:

  • D can NOT add/delete sites to/from their NGI.
  • D can NOT update the certification status of member sites.
  • D can NOT approve or reject role requests.

Roles

  • At Site level
    • Site Administrator - person responsible of maintaining a grid site and associated information in GOCDB (C Level)
    • Site Security officer - official security contact point at site level (C' Level)
    • Site Operations Deputy Manager - The deputy manager of operations at a site (C' Level)
    • Site Operations Manager - The manager of site operations (C' Level)
  • At NGI/Regional level
    • Regional First Line Support - Staff providing first line support for an NGI (D Level)
    • Regional Staff (ROD) - staff involved in Operations Centre activities such as user/operations support (D Level)
    • NGI Security officer - official security contact point at regional level (D' Level)
    • NGI Operations Deputy Manager - Deputy manager of NGI operations (D' Level)
    • NGI Operations Manager - Manager of NGI operations (D' Level)
  • At Project level
    • COD staff - COD staff (E Level)
    • COD administrator - People administrating Central COD roles (E Level)
    • EGI CSIRT Officer - official security contact point at project level (E Level)
    • Chief Operations Officer (COO) - The EGI Chief Operations Officer (E Level)

Permissions associated to roles

GOCDB roles and permissions are based on whether the considered object is owned or not. In the table below the following definitions apply:

  • Owned group: a group on which the role applies (ROC, NGI, project)
  • Owned site: a site on which the role applies, or belonging to an owned group
  • Owned service endpoint: a service endpoint belonging to an owned site

Each role has a set of associated permissions which apply on the role's scope (site, region or project). Main permissions are summarised in the table below

Action A) Unregistered users B) Registered users with no role C) Site level users C' ) Site Management Level Users
D) NGI level users D' ) NGI Management Level Users E) Project level users
Add a site to an owned group irr. irr. irr. irr. no yes irr.
Add a site to a non owned group no no no no no no no
Add a service endpoint to an owned site irr. irr. yes yes yes yes irr.
Add a service endpoint to a non owned site no no no no no no no
Add a downtime to an owned service endpoint irr. irr. yes yes yes yes irr.
Add downtime to a non owned service endpoint no no no no no no no
Update information of an owned site irr. irr. yes yes yes yes irr.
Update information of a non owned site no no no no no no no
Update certification status of an owned site irr. irr. no no no yes yes
Update certification status of a non owned site no no no no no no yes
Update information of a owned service endpoint irr. irr. yes yes yes yes irr.
Update information of a non owned service endpoint no no no no no no no
Update information of an owned group irr. irr. irr. irr. yes yes irr.
Update information of a non owned group no no no no no no no
Update own user account details irr. yes yes yes yes yes yes
Update other user's account no no no no no no no
Update a downtime on an owned service endpoint irr. irr. yes yes yes yes irr.
Update a downtime on a non owned service endpoint no no no no no no no
Delete an owned site irr. irr. no no no no no
Delete a non owned site no no no no no no no
Delete an owned service endpoint irr. irr. yes yes yes yes irr.
Delete a non owned service endpoint no no no no no no no
Delete an owned group irr. irr. irr. no no no irr.
Delete a non owned group no no no no no no no
Delete a downtime on an owned service endpoint irr. irr. yes yes yes yes irr.
Delete a downtime on a non owned service endpoint no no no no no no no
Delete your own user account irr. yes yes yes yes yes yes
Delete other user's account no no no no no no no
Register a new user account yes irr. irr. irr. irr. irr. irr.
Request a new role no yes yes yes yes yes yes
Approve a role request on an owned group irr. irr. no no no yes yes
Approve a role request on an owned site no no no yes no yes irr
Approve a role request on a non owned site or group no no no no no no no
Reject a role request on an owned group no no no no no yes irr.
Reject a role request on an owned site no no no yes no yes irr
Reject a role request on a non owned site or group no no no no no no no
Revoke an existing role on an owned object irr. irr. no yes no yes irr.
Revoke an existing role on a non owned object no no no no no no no
Retrieve an existing account/ change certificate DN yes yes yes yes yes yes yes


Requesting roles for your account

There are 2 ways to request new roles.

  • By clicking on the manage role link (sidebar, user status panel)
    • the first form allows you to choose the entity (site or group) on which you want to request a role
    • the second form lets you choose the role you want to apply for
  • By clicking on the request role link from site detail pages or group detail pages.
    • displayed form lets you choose the role you want to apply for

Once made, role requests have to be validated before the role is granted to you. This part of the process is described in the next section.

Approving/revoking accounts, roles and other actions

Changing your certificate DN

Moved to: #Changing_your_accountID

Approving role and change requests

When a registered user applies for a role, the request has to be validated by someone who has the proper permissions to grant such a role. If you request a role on a given entity, any user with a valid role on that entity or above will be able to approve your request.

Example - If you request a "site administrator" role on site X, then the following users can approve your request:

  • site administrators and security officers of site X
  • regional operations staff, managers and deputies of the Operations Centre to which site X belongs
  • GOCDB admins

Role requests you can approve are listed on the Manage roles page (accessible by clicking the Manage roles link in the user status panel in the sidebar).

In order to approve or decline role requests, simply click on the accept or deny links in front of each role request.

Revoking roles

If a user within your scope has a role that needs to be revoked, you can do this from the user's page, where user's details are listed along with his/her current roles. To revoke a role, simply click on the role name then on the revoke link at the top right of the role's details page.

Note: This works for other users within your scope but also for yourself. However just note that if you revoke your own roles you may not have proper permissions to recover them afterwards.

NGIs (Site Group)

An NGI forms a grouping of Sites in GOCDB. GOCDB stores the following information about these groups. The main page listing groups actually shows NGIs/ROCs, and is available from

  • List of NGIs/ROCs and associated contacts, linked from the main menu


Each NGI has its own listing page, accessible by clicking on the "view" link in group listing pages. A group details page shows users with a role on that group, as well as member sites and associated contacts and roles.

Adding NGIs

Adding groups is not possible through the Input System web interface. If you want to start the registration process of a new NGI, please follow the procedure described on:

Integration of the new group in GOCDB is part of the procedure but has to be done by GOCDB admins.

Editing Groups

To edit a group, simply click on the "edit" link at the top of the group's details page.


Deleting Groups

This operation is not allowed.


Sites

Definition

A site (also known as a Resource Centre) is a grouping of grid resources collating multiple Service Endpoints (SEs). Down times are recorded on selected SEs of a site. GOCDB stores the following information about sites (non exhaustive list). Note, when editing values in the portal, mandatory fields are marked with '*':

  • A unique (short) name - case sensitive (GOCDB and GoCDB are considered different)
  • An official (long) name
  • A domain name for the Site/Resource Centre
  • The home web URL of the Site/Resource Centre
  • A contact email address and telephone number
    • Emergency e-mail for a fast response time in case of urgent problem
    • Alarm e-mail is WLCG Tier1 site specific (used as part of a WLCG workflow for dealing with specific monitoring alarms)
  • A security contact email address and telephone number
  • The site timezone
  • The site's GIIS URL (Case Sensitive - Please ensure you enter your Site name which is usually encoded in the URL in the correct case!).
    • e.g. ldap://bdii-rc.some-site.uk:2170/mds-vo-name=SITE-NAME,o=grid (if your GOCDB site name site name is upper case)
  • A mandatory human readable description of the site
  • The site's latitude, longitude and location
  • Production Infrastructure: The site's intended target infrastructure. This specifies the infrastructure that the site's services deliver to. This has one of the following values:
    • Production (with this target infrastructure, the EGI site certification transition rules apply)
    • Test (in future, if the site delivers to this infrastructure, then its Certification status will be fixed to 'Candidate').
  • ROC [GROUP] - The NGI or Region of the site
  • Country
  • IP address range within which the Site/Resource Centre's services run
    • IP/netmask (x.x.x.x/x.x.x.x). To specify multiple IP/netmask values, use a comma or semi-colon separated list with no spaces, e.g. 1.2.3.4/255.255.255.0,1.2.3.5/255.255.255.0

Manipulating sites

Viewing sites

A site listing page shows a listing of all the sites in the database, with controls to page through the listing. The table headers can be clicked to set the ordering (ascending or descending).

Each site also has its own listing page. By clicking the link to view a site, you can see all of the site's information

  • Site listing page is available from the sidebar by clicking on the Browse Sites link.
  • sites belonging to a given Operations Centre are also listed from the group details pages (see below)

Adding a site

Provided you have proper permissions (check the permissions matrix in the #Permissions_associated_to_roles section), you can add a site by clicking on the Add a New Site link in the sidebar. Simply fill the form and validate.

Note: If you just registered as site admin and want your new site to be registered in GOCDB, please contact your NGI representative.

Editing site information

The editing process will show you the same form as the adding process. To edit a site, simply click the "edit" link on top of the site's details page.

Renaming a site

Provided you have permissios, you can change the Short Name, Official Name and GIIS URL to the new Resource Center details. For more information regarding the site renaming procedure please see: PROC15

Removing a site

Site deletion is not allowed in GOCDB. If a site stops operation, its certification status should be set to "closed". See the section on #Changing_Site_Certification_Status for more information

Changing Site Certification Status

For each site that delivers to the 'Production' Target Infrastructure, GOCDB stores and shows information about its certification status. This reflects the different steps of the official SA1 site certification procedure which typically follows:

  • Candidate -> Uncertified -> Certified.

The different possible certification statuses are:

  • Candidate: the Resource Centre is in under registration according to the registration process described in the RC registration certification procedure. A site will have CANDIDATE status only during certification.
  • Uncertified: site information has been validated by the Operations Centre and is ready to be moved to certified status (again). The certification status of a site can only be changed by a user with a higher level 'Regional' (or EGI 'Project') level role. This usually means that only regional managers/deputies/staff can update the status of a site that belongs to that region, see #Permissions_associated_to_roles.
  • Certified: the Operations Centre has verified that the site has all middleware installed, passes the tests and appears stable.
  • Suspended: Site does temporarily not conform to production requirements (e.g. minimum service targets - see the Resource Centre OLA, security matters) and requires Operations Centre attention. A site can be suspended for a maximum of 4 months after which it must be re-certified or closed.
  • Closed: Site is definitely no longer operated by EGI and is only shown for historic reasons.


Clarifications:

  • The uncertified status would generally be an information that a site is ready to start certification procedure (again). "uncertified" can also be used as a timewise unlimited state for sites having to keep an old version of the middleware for the absolute needs of an important international VO or to flag a site coping with Operations Centre requirements but not with EGI availability/reliability thresholds.
  • Suspended is always having a temporary meaning. It is used to flag a site temporarily not coping with with EGI availability/reliability thresholds or security requirements, and which should be closed or uncertified by its Operations Centre within 4 months. When being suspended, sites can express that they want to pass certification again. The suspened status is useful to EGI and to the Operations Centre themselves to flag the sites that require attention by the Operations Centre.
  • The closed status should be the terminal one. Suspended is not a terminal state.


The following site state transitions are allowed:

  • candidate -> uncertified
  • candidate -> closed
  • uncertified -> certified
  • certified -> suspended
  • certified -> closed (on site request)
  • suspended -> uncertified
  • suspended -> closed


The following transitions are explicitly forbidden:

  • suspended -> certified
  • candidate -> something else but uncertified and closed
  • closed -> anything else


Going with the definition of the suspended status, Operations Centre managers have to regularly give their attention to all their suspended sites, so that they are processed within the given maximum time of four months. Sites being in suspended should either be set to closed or brought back in production via the uncertified status.

More information about site certification statuses can be found in SA1 certification and operation procedures documents:

Note: Site certification status cannot be changed by site administrators, and requires intervention of Operations Centre staff.



Defining Pay4Use Properties

Service Endpoints

Definition

A service endpoint is a single entity formed by a hostname, a hosted service and a URL.

GOCDB stores the following information about service endpoints (non exhaustive list):

* The fully qualified hostname of the machine
* The hosted service (see service types below)
* The URL to reach the endpoint
* 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 endpoints per machine.

Example: the machine myhost.domain.org runs a CE, an UI and a UnicoreX service. This will show up in GOCDB as 3 Service Endpoints:

Note that a single host can also specify multiple services of the same service type.

Manipulating service endpoints

Viewing service endpoints

There are different pages in GOCDB where service endpoints are listed:

  • A full service endpoints listing page, that shows a listing of all the endpoints in the database, with controls to page through the listing. The table headers can be clicked to set the ordering.
  • Site details page, where all the service endpoints belonging to this site are listed

Each endpoint also has its own listing page. By clicking the link to view a service endpoint, you can see all associated information.

  • Service Endpoints listing page is available from the side menu in GOCDB4 by clicking on the Browse Service Endpoints link.

Adding Service Endpoints

There are 2 ways to add new service endpoints to GOCDB, provided you have proper permissions (check the permissions matrix in the #Permissions_associated_to_roles section):

  • 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 a New Service Endpoint 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 endpoint information

The editing process will show you the same form as the adding process. To edit a service endpoint, simply click the "edit" link on top of the endpoint's details page.

Removing a service endpoint from a site

to deactivate a service endpoint you have permissions on, simply clic on the "delete" link on top of the endpoint's details page. The interface asks for confirmation before proceeding.

Specific Service Endpoint fields and their impact

"beta" flag (t/f)

This indicates whether the service is a beta service or not (part of the staged rollout process). Beta is the equivalent at service level of the former EGEE Pre-Production Service (PPS)

Host DN

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 allowed chars, see GFD.225.

"production" flag (t/f)

The services Production flag indicates if this service delivers a production quality service to the infrastructure it belongs to (EGI).

  • Non-production services 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 dashboard.
  • If true, then the Monitored flag must also be true: All production resources MUST be monitored (except if the service type is a VOMS or emi.ARGUS)
  • 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 endpoint won't be tested.

Usage of PRODUCTION and MONITORED flags for EGI Service Endpoints

From 02/12/2014 all production services MUST be monitored (except for emi.ARGUS and VOMS service types).

Production and Monitored

  • Operations Dashboard: A failing test of production service endpoints generates an alarm in the ROD Operations Dashboard.
  • Availability calculation: The service endpoint test results are considered for Availability computation (if and only if the service type associated to the endpoint is one of those included in Availability computation)

Non-Production and Monitored: YES/NO

  • Availability calculation: If Monitored is set to YES, Service Availability Monitoring (SAM) will test the service, but SAM test results are ignored by the Availability Computation Engine (ACE).
  • Availability calculation: Non-production service endpoints are not considered for site availability calculations.
  • Operations Dashboard: If Monitored is set NO, the service endpoint is ignored by SAM and no alarms are raised in the Operations Dashboard in case of CRITICAL failure.
  • SAM tests for non-production services generate alarms into the ROD Operations Dashboard in case of CRITICAL failure of the test. These alarms are visible in the Operations Dashboard and are tagged as "non production".

Service Groups

A service group is an arbitrary grouping of existing service endpoints that can be distributed across different physical sites and users that belong to the SG (SGs were previously known as 'Virtual Sites'):

  • Each service that appears in a group must already exist and be hosted by a physical site.
  • A service group role does not extend any permissions over its child services. This means that you cannot declare a downtime on the services that you group together or modify the service attributes.
  • Any GOCDB user can create their own service group and as the 'Service Group Administator' you can control subsequent user membership requests to the SG (everything is logged, including who created the service group).
  • GOCDB users can request to join an existing service group by finding the target SG and requesting a role on that SG.
  • Service groups are typically used for monitoring a particular collection of services and/or users using the GOCDB 'get_service_group' and 'get_service_group_role' PI methods.
  • SG memebers can be listed using the get_service_group_role PI method.
  • PI doc:
  • If you have any further use-cases or suggestions, please submit a ticket to RT.


NGI Core Services

NGIs can register a number of ‘NGI-Core’ services in GOCDB. A core NGI service is one that is used to calculate the availability and reliability of the NGI. These services fall under the responsibility of the NGI and provide production quality (no testing instances). NGIs can distinguish/flag their core services from their other (non-core) services using one of two ways (see A and B below).

Core Service Requirements

The service instance MUST:

Required Service Types

The following service types are mandatory and all NGIs in the EGI scope should define instances of these services:

  • ngi.SAM (Mandatory)
  • emi.ARGUS (Mandatory) (NGI ARGUS)
  • Top-BDII (Mandatory)

Other Mandatory services, depending on middleware deployed by sites under NGI responsibility, are listed here

NGIs should also register their custom core services like accounting, helpdesk if they are registered in GOCDB (for a list of other common core service types see: https://wiki.egi.eu/wiki/NGI_services_in_GOCDB)

Registering NGI Core Services

NGI core services can be grouped/flagged in one of two ways:

  • A) By creating a ‘NGI_XX_SERVICES’ Site and adding their core services under this site. This site must be scoped as ‘NGI’ and define a certification status of ‘Certified’.
  • B) By creating a ‘NGI_XX_SERVICES’ ServiceGroup and adding their core services to this ServiceGroup.

It is important that these core service Sites/ServiceGroups adhere to the ‘NGI_XX_SERVICES’ naming scheme. For further details, including a list of existing ‘NGI_XX_SERVICES’ please see: https://wiki.egi.eu/wiki/NGI_services_in_GOCDB

Downtimes

Definition

A downtime is a period of time for which a service is declared to be inoperable. Downtimes may be scheduled (e.g. for software/hardware upgrades), or unscheduled (e.g. power outages). GOCDB stores the following information about downtimes (non exhaustive list):

  • The downtime classification (Scheduled or unscheduled)
  • The severity of the downtime
  • The date at which the downtime was added to GOCDB
  • The start and end of the downtime period
  • A description of the downtime
  • The entities affected by the downtime

Manipulating downtimes

Viewing downtimes

There are different pages on which downtimes are listed:

  • A "Recent and Planned" page , linked from the main menu, this provides a window to the EGI hosted information about downtimes. (Nb: This service requires users to add an exception to allow this window to render correctly)
  • A "Active & Imminent" page, linked from the main menu, that allows users to see currently active downtimes and downtimes planned in the coming weeks.
  • Site details page, where all the downtimes associated to the site are listed
  • Service endpoint details page, where all the downtimes associated to the service endpoint are listed
  • Service group details page, where all the downtimes associated to the service group are listed

Each downtime has its own listing page, accessible by clicking on the "view" link in downtime listing pages.

Adding downtimes

Provided you have proper permissions (check the permissions matrix in the #Permissions_associated_to_roles section), you can add a downtime by clicking on the Add a Downtime link in the sidebar.

This is done in 2 steps:

  • enter downtime information
  • specify the full list of impacted services in case there is more than one or select an site to select all the sites associated services.


Please note:

  • All dates have to be entered in UTC.
  • A downtime can be retrospectively added if its start-date is less than 48h in the past (giving a 2 day window to add).
  • downtime classification (scheduled/unscheduled) is determined automatically (see #Scheduled or unscheduled? section)

Editing downtime information

  • To edit a downtime, simply click the "edit" link on top of the downtime's details page.
  • A downtime can be retrospectively updated if its start-date is less than 48h in the past (giving a 2 day window to modify).
  • Note there are limitations to downtime editing, especially if it has already started, or is due to start in the next 24hrs or is finished. See #Downtime shortening and extension section for more details.

Removing downtimes

To delete a downtime, simply click the delete link on top of the downtime's details page. For integrity reasons, it is only possible to remove downtimes that have not started.

"Good practices" and further understanding

Scheduled or unscheduled?

Depending on the planning of the intervention, downtimes can be:

  • Scheduled: planned and agreed in advance
  • Unscheduled: planned or unplanned, usually triggered by an unexpected failure or at a short term notice

EGI defines precise rules about what should be declared as scheduled or unscheduled, based on how long in advance the downtime is declared. These rules are described in MAN02#How_to_manage_an_intervention and are enforced as follows:

  • All downtimes declared less than 24h in advance will be automatically classified as UNSCHEDULED
  • All other downtimes will be classified as SCHEDULED

Notes:

  • A downtime can be retrospectively declared and/or updated if its start-date is less than 48h in the past (giving a 2 day window to add/modify).
  • Although 24h in advance is enough for the downtime to be classified as "scheduled", it is good practice to declare it at least 5 working days before it starts.


WARNING or OUTAGE?

When declaring a downtime, you will be presented the choice of a "severity", which can be either WARNING or OUTAGE. Please consider the following definitions:

  • WARNING means the resource is considered available, but the quality of service might be degraded. Such downtimes generate notifications, but are not taken into account by monitoring and availability calculation tools. In case of a service failure during the WARNING period an OUTAGE downtime has to be declared, cancelling the rest of the WARNING downtime. (The WARNING flag now replaces the former AT_RISK flag).
  • OUTAGE means the resource is considered as unavailable. Such downtimes will be considered as "IN MAINTENANCE" by monitoring and availability calculation tools.

Downtime shortening and extension

Limition rules to downtime extensions are enforced in GOCDB as follows:

  • if the downtime is scheduled to start within the next 24hrs or has started, it can't be modified (it has already been read/logged in other systems).
  • Once created, downtimes can be shortened but not extended
  • If for any reason a downtime already declared needs to be extended, the procedure is to add another adjacent downtime, before or after.
  • Any downtime can be shortened to any date which is not in the past.
  • A downtime's start and end time cannot be changed once the downtime has finished

Service types

In GOCDB a service type is a technology used to provide a service. Each service endpoint in GOCDB is associated with a service type. Service types are pieces of software while service endpoints are a particular instance of that software running in a certain context.

Service Type Naming Scheme

  • Service types include grid middleware and operational services.
  • This attribute corresponds to the Glue2 'Service.Type' attribute and is defined as the 'Type of service according to a namespace based classification (the namespace MAY be related to a middleware name, an organisation or other concepts).'
  • The naming scheme for new service types in GOCDB therefore generally follow a reverse DNS style syntax, usually naming the technology provider/project followed by technology type in lowercase, i.e. ‘<provider>.<type>’ (e.g. ‘org.openstack.swift’).
  • Please note, this syntax does not necessarily indicate ownership, the main objective is to avoid name clashes between services. For example, different projects may have similar services but these may be modified/customised just enough to merit a different prefix or service type name.
  • Glue2 defines a service type list at: [Glue2 Enums] [Glue2 service types].
  • The Glue2 and GOCDB recommendation is to use lowercase (legacy enum values do exist that use camelCase).

These service types are used at some grid sites within EGI but aren't EGI operational tools or a part of the core middleware distributions (EMI, gLite, ARC, UNICORE, Globus etc).

Service Type List

To request a new service type, please submit a request for a new service type (described below).

Operational Components (middleware agnostic)

  • Site-BDII: [Site service] This service collects and publishes site's data for the Information System. All grid sites MUST install one Site-BDII. For cloud sites eu.egi.cloud.information.bdii MUST be installed.
  • Top-BDII: [Central service] The "top-level BDII". These collect and publish the data from site-BDIIs. Only a few instances per region are required.
  • MyProxy: [Central service] MyProxy is part of the authentication and authorization system. Often installed by sites installing the WMS service.
  • egi.APELRepository: [Central service] The central APEL repository
  • egi.AccountingPortal: [Central service] The central accounting portal
  • egi.GGUS: [Central service] The central GGUS
  • egi.GOCDB: [Central service] The central GOCDB
  • egi.MSGBroker: [Central service] The central message broker
  • egi.Portal: [Central Service] for monitoring generic web portals who dont have a specific service type
  • MSG-Broker: [Central service] A broker for the backbone messaging system.
  • egi.MetricsPortal: [Central service] The central metrics portal
  • egi.OpsPortal: [Central service] The central operations portal
  • egi.GRIDVIEW: [Central service] The central gridview portal
  • egi.GSTAT: [Central service] The central GStat portal
  • egi.SAM: [Central service] The central SAM monitoring
  • ngi.SAM: [Regional Service] NGI-level SAM monitoring box
  • vo.SAM: [Regional Service] VO-level SAM monitoring box
  • site.SAM: [Regional Service] Site-level SAM monitoring box
  • ngi.OpsPortal: [Regional service] NGI-level regional operations portal instance
  • eu.egi.MPI: Defines a dummy Service Type to enable the running of MPI tests for services providing MPI capabilities. Sites must have one instance of this Service Type associated with a CREAM-CE service. For details see https://wiki.egi.eu/wiki/VT_MPI_within_EGI:Nagios
  • argo.poem: POEM is system for managing profiles of probes and metrics in ARGO system.
  • argo.mon: ARGO Monitoring Engine gathers monitoring metrics and publishes to messaging service.
  • argo.consumer: ARGO Consumer collects monitoring metrics from monitoring engines.
  • argo.computeengine: ARGO Compute Engine computes availability and reliability of services.
  • argo.api: ARGO API service for retrieving status and A/R results.
  • argo.webui: ARGO web user interface for metric A/R visualization and recalculation management.
  • egi.aai.saml: EGI AAI CheckIn SAML interface. Enables federated access to EGI services and resources using Security Assertion Markup Language (SAML). Provided by GRNET.
  • egi.aai.oidc: EGI AAI CheckIn OpenID Connect interface. Enables federated access to EGI services and resources using OpenID Connect (OIDC). Provided by GRNET.
  • egi.aai.tts: EGI AAI CheckIn token translation service. Enables the translation between different authentication and authorisation protocols. Provided by GRNET.


Middleware (ARC, gLite, Unicore)
ARC Middleware

  • ARC-CE: [Site service] The Compute Element within the ARC middleware stack.
  • SGAS: [Site service] An accounting service used by ARC.
  • org.nordugrid.arex: [Site Service] ARC version 3 Compute element.

gLite Middleware

  • CE: [OBSOLETE Site service] The LCG Compute Element. Currently the standard CE within the gLite middleware stack. Replaced by the CREAM CE.
  • gLite-CE: [OBSOLETE Site service] The gLite Compute Element is now obsolete and is not supported. Please avoid using this middleware service.
  • CREAM-CE: [Site service] The CREAM Compute Element is the new CE within the gLite middleware stack.
  • APEL: [Site service] This is a "dummy" Service Type to enable the monitoring tests for APEL accounting. All sites must have one instance of this Service Type, associated with a CE.
  • MON: [OBSOLETE Site service] The gLite MonBox hosts the site R-GMA services.
  • UI: [User service] The User Interface. Can be installed by users but more commonly installed by a site.
  • SRM: [Site service] Storage Resource Manager. Mandatory for all sites running an SRM enabled storage element.
  • SRM.nearline: [Site service] Storage Resource Manager for tape only.

* SRM.online: [Site service] Storage Resource Manager for disk only.

  • Classic-SE: [OBSOLETE Site service] The Classic Storage Element is now obsolete and is not supported. Please avoid using this middleware service.
  • Central-LFC: [Central service] An instance of the gLite file catalogue which holds entries for all files owned by a particular VO. NOTE: An LFC can be both Central and Local.
  • Local-LFC: [Site service] An instance of the gLite file catalogue which holds entries for files owned by a particular VO, at your site. NOTE: An LFC can be both Central and Local.
  • WMS: [Central service] gLite Workload Management Service. Acts as the broker for matching user jobs to available computing resources.
  • RB: [OBSOLETE Central service] The LCG Resource Broker is now obsolete and is not supported. Please avoid using this middleware service.
  • VOMS: [Central service] VO Management System. Part of the authentication and authorization system. This service only needs to be installed on the request of a VO.
  • LB: [Central service] gLite Logging and Bookkeeping. Usually installed by sites running a WMS. One LB service can support several WMS instances.
  • AMGA: [Central service] gLite metadata catalogue. This service only needs to be installed on the request of a VO.
  • FTM: [Site service] gLite File Transfer Monitor. Monitors the FTS service at a site.
  • FTS: [Central service] The gLite File Transfer Service manages the transfer of files between sites. This service only needs to be installed on the request of a VO.
  • VO-box: [Site service] The gLite VO box allows a VO to run their own services at a site. This service only needs to be installed on the request of a VO.
  • gLite-APEL: [Site service] The gLite-APEL hosts the site Accounting client (3.2 replacement of the MonBox)
  • gLExec: [Site service] A light-weight gatekeeper to authenticate and authorize credentials according to local site policy and execute commands. https://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/GLExec
  • emi.ARGUS: [Site service] The Argus Authorization Service renders XACML authorization decisions for distributed services, based on policies
  • ngi.ARGUS: [Central Service] Distinguishes site Argus instances (emi.ARGUS) from NGI ones (ngi.ARGUS). While servicegroups can be used for this in gocdb, this is needed for backward-compatibility with the monitoring.

Unicore Middleware

  • eu.unicore.UnicorePortal UNICORE Portal service allows users to access a UNICORE Grid via the web browser. Service be used by users instead of standalone clients like UCC and URC to access resources and submit jobs. The UNICORE Portal server is available for download at UNICORE site: http://unicore.eu/download/unicore6/. It is possible in the future that each NGI supporting UNICORE middleware will deploy at least one instance.
  • unicore6.Registry: [Central service] All UNICORE services register here; clients ask the registry for available services in the Grid. Normally one Registry per Grid infrastructure which collects URLs of services.
  • unicore6.Gateway: [Site service] Sits in front of one or more UNICORE services as a gateway to the internet. Normally one Gateway per site.
  • unicore6.TargetSystemFactory [Site service] used as an entry-point for submitting single jobs. It can create Target System Services (TSSs) and submit jobs to those TSSs.
  • unicore6.StorageFactory [Site service] Creates StorageManagement instances. A user can create dynamic storage management services for own purposes with it. Often used to provide filespace during workflow execution.
  • unicore6.StorageManagement [Site service] Provides an abstract filesystem-like view on a storage resource. A Storage Management Service (SMS) can be created by a Storage Factory or can be configured statically way by a config file.
  • unicore6.ServiceOrchestrator [Site service] Handles dispatching of a workflow's atomic jobs, and brokering. Normally there is one per grid infrastructure.
  • unicore6.WorkflowFactory [Site service] Used as an entrypoint for submitting workflow jobs. The Workflow factory is creating workflow instances and can submit workflows to them. It is the workflow submission equivalent to the Target System Factory used for single job submission.
  • unicore6.UVOSAssertionQueryService [Site service] Provides data and user information via the SAML standard as needed for authorization and environment customization.

Globus Middleware

  • GRAM5: [Site service] job submission service for Globus version 5.x (GRAM5).
  • globus-GRIDFTP: [Site service] storage endpoint and data transfer service for the Globus middleware stack.
  • globus-GSISSHD: [Site service] certificate based interactive login service for the Globus middleware stack.
  • MyProxy: [Site service] MyProxy is part of the authentication and authorization system.

QosCosGrid (QCG) Middleware

  • QCG.Computing [Site service] A compute component based on the OGF Basic Execution Service (BES) with advanced reservation support.
  • QCG.Notification [Site service] A notification middleware component using a brokered version of the OASIS WS-Notification standard.
  • QCG.Broker [Site service] QosCosGrid resource management and brokering service.

EDGI Middleware (European Desktop Grid Initiative)

  • dg.CREAM-CE CREAM gateway to Desktop Grid
  • dg.3GBridge The 3G Bridge (Generic Grid Grid Bridge) is designed to be used as a mediator between different types of Grid middleware.

Cloud

Other

* ch.cern.cvmfs.stratum.1 Service component (stratum.1) of CernVM file system http://cernvm.cern.ch/portal/filesystem

  • uk.ac.gridpp.vac A virtual machine factory system for operating clusters at grid sites
  • hu.guse.ws-pgrade WS-PGRADE/gUSE-based science gateway deployment
  • org.opensciencegrid.htcondorce A special configuration of the HTCondor software designed to be a job gateway solution
  • uk.ac.gridpp.vcycle Vcycle manages the lifecycle of VMs running jobs on cloud resources. LHCb, ATLAS, CMS, and GridPP DIRAC VMs
  • webdav Service with extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers.

Custom Service Types
In order to control the proliferation of custom service types, please consider submitting a request for a new service type (described below) before using CUSTOM_SERVICE.

* CUSTOM.pl.plgrid.Bazaar SLA negotiation system between users and resource providers from NGI_PL grid

Adding new services types

Please feel free to make a request for a new service type. For CUSTOM service types, we would like to make this process as light-weight as possible. However, currently all new service type requests need to be assessed by EGI via lightweight review process (by OMB and EGI Ops) so that only suitable types are added to GOCDB and to prevent duplication.

You can submit your request in one of the following ways:

Please specify the following information as part of your request:

- name of service:
- high-level description of the service functionality:
- project/community/organization maintaining the software:
- scope of deployment (number of instances and by which organizations):
- contact point (name/e-mail address):

Note - please provide a suggested SE type name following the naming scheme described above (technology provider's reversed domain . software name) and a brief sentence to describe the service type.

Guidelines here for adding custom service types to SAM for monitoring.

Data Visibility / Scopes

  • Scope tags are used to group Grid entities such as Sites, Services and ServiceGroups into flexible categories. A single entity can define multiple scope tags, allowing the resource to be associated with different categories without duplication of information. This is essential to maintain the integrity of topology information across different infrastructures and projects.
  • The GOCDB admins control which scope tags are made available to avoid proliferation of tags (user defined tags are reserved for the extensibility mechanism).
  • As an example, a site’s scope list could aggregate all of the scopes defined by its child services. In doing this, the site scope list becomes a union of its service scopes plus any other site specific tags defined by the site.
  • By defining scope tags, resources can be ‘filtered-by-scope-tag’ when querying for data in the PI using the ‘scope’ and ‘scope_match’ parameters, see GOCDB Programmatic Interface (GOCDB-PI) for details.

Clear Separation of Concerns

It is important to understand that scopes and Projects are distinct:

  • Projects are used to cascade roles and permissions over child objects
  • Scope tags are used to filter resources into flexible categories/groupings
  • Scope tags can be created to mirror the projects. For example, assuming two projects (e.g. EGI.eu and EUDAT), two corresponding tags may be defined.
  • In addition, it is also possible define additional scopes for finer grained resource filtering e.g. ‘SubGroupX’ and ‘EGI_TEST’.
  • The key benefit: A clear separation of concerns between cascading permissions and resource filtering.

EGI Scopes

  • To make a Site, Service or ServiceGroup visible to EGI, the resource's 'EGI' scope tag check box must be ticked. EGI scoped resources are exposed to the central operational tools for monitoring and will appear in the central operations portal.
  • Un-ticking the EGI checkbox and selecting the 'Local' scope makes the selected object invisible to EGI; it will be hidden from the central operation tools (it will not show in the central dashboard and it will not be monitored centrally). This can be useful if you wish to hide certain parts of your infrastructure from EGI but still have the information stored and accessed from the same GOCDB instance.
  • A use-case for non-EGI sites/services is to hide those entities from central EGI tools, but to include those sites/services for use by regional versions of the operational tools (such as regional monitoring). To enable regional monitoring of non-EGI sites/services using SAM see [original change request] and [Add support for GOCDB scope]
  • Note that exposing a site / service endpoint as EGI does not override the production status or certification status fields. For example if a site isn't marked as production it won't be monitored centrally even if it's marked as visible to EGI.
  • New scope tags can be requested using any of these methods:

Reserved Scope Tags

  • Some tags may be 'Reserved' which means they are protected - they are used to restrict tag usage and prevent non-authorised sites/services from using tags not intended for them.
  • Reserved tags are initially assigned to resources by the gocdb-admins, and can then be optionally inherited by child resources (tags can be initially assigned to NGIs, Sites, Services and ServiceGroups).
  • When creating a new child resource (e.g. a child Site or child Service), the scopes that are assigned to the parent are automatically inherited and assigned to the child.
  • Reserved tags assigned to a resource are optional and can be de-selected if required.
  • Users can reapply Reserved tags to a resource ONLY if the tag can be inherited from the parent Scoped Entity (parents include NGIs/Sites).
    • For Sites: If a Reserved tag is removed from a Site, then the same tag is also removed from all the child Services - a Service can't have a reserved tag that is not supported by its parent Site.
    • For NGIs: If a Reserved tag is removed from an NGI, then the same tag is NOT removed from all the child Sites - this is intentionally different from the Site->Service relationship.
  • To request a reserved scope tag, an approval is required from the operators of the relevant resources. Details on who to contact are listed below. Once authorisation is given, please contact the GOCDB admins with details of the approval (e.g. link to a GGUS ticket that approves the tag assignment).

FedCloud Reserved Tag

  • Tag for resources that contribute to the EGI Federated Cloud. To request this tag, please contact the FedCloud operators / EGI Operations.

Elixir Reserved Tag

  • Tag for resources that contribute to the EGI Federated Cloud. To request this tag, please contact the operators of the ‘ELIXIR’ NGI in GOCDB.

WLCG Reserved Tags

  • A number of reserved scope tags have been defined for the WLCG:
    • The ‘tierN’ tags should be requested for WLCG sites that are defined in REBUS (a management view of the WLCG infrastructure/sites). To request a ‘tierN’ tag, raise a ticket against the REBUS support unit in GGUS.
    • For the experiment VO tags (alice, atlas, cms, lhcb), raise a ticket with the relevant VO support unit.
    • The wlcg tag is a generic catch-all tag for sites/services with either tierN and VO tags and is used to gain an overall view of the WLCG infrastructure.

SLA Reserved Tag

  • Entitities covered by an EGI VO SLA
    • This Tag will only be applied at the request of EGI operations

Extension Properties

NOTE: From GOCDB 5.8 (Autumn/Winter 2016) keys must be unique for a given site, service, or service endpoint, or service group.

  • Sites, Services, service endpoints, and Service Groups can be extended by adding custom key-value pairs (this follows the GLUE2 extensibility mechanism).
  • Extension properties address a number of use cases, such as filtering Sites and/or Services that define particular properties, e.g. 'charging rate': https://rt.egi.eu/rt/Ticket/Display.html?id=3764
  • Selected methods in the GOCDB PI support the 'extensions' URL parameter. This parameter is used to filter resources according to the extensions they define (described below).
  • Properties are rendered in the XML results of the Site/Service/ServiceGroup using the <EXTENSIONS> XML element, for an example see a sample output from get_service_endpoint
  • Note, anyone with permissions over the target entity can add extension properties to that object.
  • This allows 'Folksonomy' building: 'a user-generated system of classifying and organizing content into different categories by the use of metadata such as electronic tags'
  • A number of use cases can be addressed; e.g. filtering Sites that support a specific property, e.g. ‘P4U_Pilot_Cloud_Wall’
  • Key/value pairs (currently) prevent certain characters from being used in their values. This includes the equals and opening/closing parenthesis chars ‘=()’. This is to simplify lexical parsing of the query. In addition, to guard against cross-site scripting attacks, the quote, double quote, semi-colon and back tick chars are also not allowed.

Extension Properties in the PI

  • Selected PI methods allow results to be filtered by extension properties via the 'extensions' PI parameter.
  • Supported methods include: get_site, get_site_list, get_service_endpoints and get_service_group, get_downtime, get_downtime_nested, get_site_list.
  • For individual method support please refer to the PI documentation: GOCDB/PI/Technical Documentation
  • The format of the 'extensions' PI parameter is one or more (key=value) pairs enclosed in brackets.
    • The value part of a (k=v) pair can be ommitted if filtering by value is not required (i.e. '(somekey=)' means select all resources that define the 'somekey' property with any value.
    • (k=v) pairs can be optionally prefixed with one of following operators: AND, OR, NOT.
    • If no operator is specified before the FIRST (k=v) pair, then AND is assumed.
    • A single operator applies to ALL the (k=v) pairs to the right of the operator until another operator is encountered.
    • An AND forms a logical conjunction with any previously specified conditions.
    • An OR forms a logical disjunction with any previously specified conditions.
    • A NOT forms a logical conjunction with any previously specified conditions (it can be read as 'AND NOT')
    • Because an OR always forms a logical disjunction with any previously specified conditions, you can’t OR against a group occurring to the right that contains multiple k=v pairs e.g. the following is not supported (if there is sufficient demand, it could be considered for a future enhancement):
      • ((k=v1)AND(k=v2)) OR ((k=v3)AND(k=v4))


Examples:

  • Eg (note no leading AND):
    • (key1=val)(key2=va2)OR(key3=val3)(key4=val4)NOT(key5=val5)(key6=val6)   is expanded to:
    • AND(key1=val)AND(key2=va2)OR(key3=val3)OR(key4=val4)NOT(key5=val5)NOT(key6=val6)    which is interpreted as:
    • (((key1=val)AND(key2=va2))OR(key3=val3)) OR(key4=val4) NOT(key5=val5) NOT(key6=val6)
  • Eg:
    • (VObing=true)AND(VObaz=true)AND(VObar=true)OR(s1p1=v1)      is equal to:
    • is equal to: ((VObing=true)AND(VObaz=true)AND(VObar=true))OR(s1p1=v1)
  • Eg:
    • (VO=food)OR(VO2=bar)AND(s4p1=v1)       is equal to:
    • ((VO=food)OR(VO2=bar))AND(s4p1=v1)
  • Eg:
    • (VO=food)(s4p1=v1)OR(VObar=true)(VObaz=true)       is equal to:
    • is equal to: ((VO=food)AND(s4p1=v1))OR(VObar=true)OR(VObaz=true)
  • Eg:
    • (VO=food)(s4p1=v1)OR(VObaz=true)AND(VObling=true)       is equal to:
    • (((VO=food)AND(s4p1=v1))OR(VObaz=true))AND(VObling=true)


To return all sites that define VO with a value of Alice:

?method=get_site&extensions=(VO=Alice)

Use no value to define a wildcard search, i.e. all sites that define the VO property regardless of value:

?method=get_site&extensions=(VO=)

NOTE: From GOCDB 5.7 (Autumn/Winter 2016) keys must be unique for a given site, service, or service endpoint, or service group. The following section of documentation has not yet been changed to reflect this.

Extensions also supports OR/AND/NOT operators. This can be used to search against multiple key values eg:

?method=get_site&extensions=AND(VO=Alice)(VO=Atlas)(VO=LHCB)

These can be used together:

?method=get_site&extensions=AND(VO=Alice)(VO=Atlas)NOT(VO=LHCB)
?method= get_service_endpoint&extensions=(CPU_HS01_HOUR=1)OR(CPU_HS02_HOUR=2)

When no operator is specified the default is AND, therefore the following:

?method= get_service_endpoint&extensions=(CPU_HS01_HOUR=1)(CPU_HS02_HOUR=2)

Is the same as:

?method= get_service_endpoint&extensions=AND(CPU_HS01_HOUR=1)(CPU_HS02_HOUR=2)

The extensions parameter can also be used in conjunction with the existing parameters previously supported:

?method=get_site&extensions=(VO=Alice)NOT(VO=LHCB)&scope=EGI&roc=NGI_UK
  • The 'site_extensions' and 'service_extensions' can also be used on the 'get_downtime' and 'get_downtime_nested_services' methods using same logic described above. Note, the <EXTENSIONS> element is not rendered in the XML output for these queries.
?method=get_downtime_nested_services&site_extensions=(eg.2=val.2)&service_extensions=(eg.2=)
?method=get_downtime&site_extensions=(eg.2=val.2)&service_extensions=(eg.2=)

Options for adding a new Project in GocDB

GocDB is multi-tenanted; it can host multiple projects in the same instance. There are a number of different deployment scenarios that can be used to support new projects detailed below. Please contact the GocDB admins/EGI Ops to request the addition of a new project.

1) Add resources (sites/services) to an existing project

  • Resources (NGIs, Sites, Services) would be hosted under an existing project, e.g. the ‘EGI’ project.
  • The new resources would be subject to the rules/roles of the existing project, such as site certification status changes and project controlled user memberships.
  • The resources could not be filtered using a custom scope tag.

2) Add resources (sites/services) to an existing project and add a new Scope tag to represent a sub-grouping

  • Resources would be hosted under an existing project, and a new scope tag would be added for the purposes of resource filtering.
  • Since the resources are still hosted under an existing project, the resources would still be subject to the rules/roles of that project such as project controller user memberships.
  • The resources could be filtered using the new scope tag, but this scope tag would not strictly represent a project, rather a sub-grouping under the existing project, e.g.
    get_services&scope=SubGroupX
    Note, resources can be tagged multiple times to declare support for multiple projects and sub-groups:
    get_services&scope=SubGroupX,EGI&scope_match=all

3) Add resources (sites/services) to a new Project and add a new Scope tag to filter by project

  • Resources would be hosted under a new project, and a new scope tag would be added named after the project for the purposes of resource filtering.
  • The resources would not be subject to the rules/roles of other projects, for example, allowing the project to control its own project memberships.
  • The resources could be filtered using the scope tag named after the new project, e.g.
    get_services&scope=ProjectX
    Note, resources can be tagged multiple times to declare support for multiple projects:
    get_services&scope=ProjectX,EGI&scope_match=all

How to and FAQ

I get an "error 12227" message when accessing GOC portal with Mozilla/Firefox

This happens when no certificate has been uploaded to your browser. Refer to the "Access to GOCDB" section for more information about GOCDB and X509 certificates.

I am responsible for a site that has recently entered the EGI infrastructure. How do I register it?

Only registered users with an approved role on an NGI can add a new site. If you are the site administrator, the first thing to do is to contact your NGI staff and ask them to add the site for you. Then, register to GOCDB (see the user account section) and ask for a site admin role for your site (see the requesting a role section). Once your role approved, you will be able to edit and change your site information.

Why can't I declare downtimes for my whole site as I used to do in GOCDB3?

For data clarity reasons, it has been decided long ago to only link downtimes to services, thus avoiding the complication of having to check both site and service downtimes to determine whether a service is up or not. The way to declare a downtime for your site is to select all the services of the site in one go when inserting the downtime.

How do I extend a declared schedule downtime?

Because of EGI policies it is not possible to extend a downtime. Recommended good practice for any downtime extension is to declare a new unscheduled downtime, starting just when the frst one finishes. please refere to the downtimes section of this documentation for more information, especially the "downtime extension" paragraph.

I have declared a downtime "at risk", and it turns out to be an outage. How can I declare this properly?

If you have declared the downtime as being at risk and an outage actually happens half way through, you need to update GOCDB to reflect the fact that your site is now down. There is currently no way of doing this by updating the downtime on the fly without having the system considering the whole downtime as being an outage. The best way to proceed is:

  • Modify end date of your "at risk" downtime, so that it ends in a few minutes
  • Enter a new "outage" downtime, starting when the other ends

How do I switch monitoring on/off for my nodes?

Monitoring status in GOCDB cannot always be switched off. If a node is declared as delivering a production service, rules apply and the node has to be monitored. If you are running a test node and want to switch monitoring off, set both "monitoring" and "production" to "N".

Why nobody has approved my role request yet?

Someone has to approve any request you make, in order to ensure nobody is trying to get inappropriate roles. If yours is not getting approved, this can either be because your request was not legitimate, or most likely because the people that are supposed to do it forgot about it. Please refer to the Roles permissions definitions section of this documentation to determine who should validate your role, and try to get in touch with them. If you are requesting a site admin role, they are likely to be your fellow site admins or your NGI operators.

I am not an EGI user but need access to GOCDB backend to retrieve information for my project. What can I do?

Accessing GOCDB backend through another way than the GOC portal web interface is out of the scope of this documentation. please refer to the technical documentation instead, which is available from  GOCDB Documentation Index.