Documentation – Configuration Database

Internal: Service information

Mon, 01 Jan 0001 00:00:00 +0000

Identity card

Property	Value
Name	Configuration Database
Description	Central registry of the infrastructure topology
URL	https://goc.egi.eu
Support Email	`gocdb-admin` `<at>` `mailman.egi.eu`
Helpdesk Support Unit	EGI Services and Service Components I__ Configuration Database (GOCDB)
Configuration Database entry	https://goc.egi.eu/portal/index.php?Page_Type=Site&id=335
Supplier	UKRI
Roadmap	N/A
Release notes	Release notes
Source code	https://github.com/GOCDB
Issue tracker for developers	https://github.com/GOCDB/gocdb/issues
Licence	Apache 2.0
Privacy Notice	Privacy notice

Internal: Access

Mon, 01 Jan 0001 00:00:00 +0000

To access the web interface of the EGI Configuration Database (GOCDB), users can either:

Use EGI Check-in with an institutional account, or
Use an X.509 digital certificate installed in the internet browser, or the local machine’s certificate store.

Users can access the system as soon as they are authenticated. However, they will only be able to update information based on their roles, and only once they will have registered a new user account.

More information about roles and associated permission is available in the Users and roles section of the documentation.

Applications requesting a specific role have to be validated by parent roles or administrators. Once granted, users can access and/or modify relevant information, according to the roles granted to them.

Using institutional account via EGI Check-in

In order to be able to access the Configuration Database with their institutional account, users need to:

Have their Identity Provider (IdP) federated in EGI Check-in (via eduGAIN or directly).
Have created an EGI Check-in account.

Important

In the case the user cannot use an IdP compliant with REFEDS R&S and REFEDS Sirtfi, the user will have to request joining a specific group, by performing the steps below. Using a compliant IdP is the preferable solution.

User should ask to join the GOCDB user group.
The access request will be managed by the EGI Operations team.

Using an X.509 digital certificate

To access the Configuration Database using a digital certificate, first obtain a certificate from one of the recognised EU-Grid-PMA Certification Authorities (CAs), then install it in your browser of choice (or import it into the certificate store of your local machine, on Windows).

Note

X.509 certificates do not support single or double quotes in the certificate’s Distinguished Name (DN). The DN below is rejected 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.

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 the EGI Configuration Database. If you need to edit data in and request roles, you will need to fill in the registration form.

To Register:

Go to the EGI Configuration Database web portal
In the left sidebar, look out for the User status panel
click on the “Register” link
fill in the form and validate

Recovering access to an existing account

Note

If you were registered but are not recognised anymore (e.g. because your certificate DN changed), do not register again! Instead, follow the steps Lost access to your Configuration Database account section.

Internal: Adding service endpoints

Mon, 01 Jan 0001 00:00:00 +0000

For monitoring purposes, each service endpoints registered into the Configuration Database, and having the flags production and monitored should include the endpoint URL information in order to be contacted by the corresponding service-specific nagios probe.

The information needed for service type are:

SRM: the value of the attribute GlueServiceEndpoint published in the Configuration Database or BDII (e.g. httpg://se.egi.eu:8444/srm/managerv2)
Cloud:
- org.openstack.nova: The endpoint URL must contain the Keystone v3 URL: https://hostname:port/url/v3
- org.openstack.swift:The endpoint URL must contain the Keystone v3 URL: https://hostname:port/url/v3
- eu.egi.cloud.accounting: for the host sending the records to the accounting repository
Other service types: the value of the attribute GlueServiceEndpoint published in the BDII

It is also possible to register additional endpoints for every services, they will also be monitored if the “Monitored” flag is set.

For having more information about managing the Service endpoints in the Configuration Database, please consult the service endpoints documentation.

Retrieving the information

For retrieving the queue URL from the BDII, you can use the command lcg-infosites, to be executed from a UI. Be sure to query a production Top BDII: you can either use the one provided by your Operations Centre or choose one from the Configuration Database

For example:

$ export LCG_GFAL_INFOSYS=egee-bdii.cnaf.infn.it:2170

$ lcg-infosites --vo ops ce | grep nikhef
 5680 15 0 0 0 dissel.nikhef.nl:2119/jobmanager-pbs-infra
 5680 17 1 1 0 gazon.nikhef.nl:8443/cream-pbs-infra
 5680 15 0 0 0 juk.nikhef.nl:8443/cream-pbs-infra
 5680 15 0 0 0 klomp.nikhef.nl:8443/cream-pbs-infra
 5680 16 0 0 0 stremsel.nikhef.nl:8443/cream-pbs-infra

In order to find the GlueServiceEndpoint URL of your SRM service, you can launch a LDAP query to your Site BDII (or directly to the SRM service):

$ ldapsearch -x -LLL -H ldap://sbdii01.ncg.ingrid.pt:2170 \
 -b "mds-vo-name=NCG-INGRID-PT,o=grid" \
 '(&(objectClass=GlueService)(GlueServiceType=SRM))' \
 GlueServiceEndpoint

dn: GlueServiceUniqueID=httpg://srm01.ncg.ingrid.pt:8444/srm/managerv2,Mds-Vo-name=NCG-INGRID-PT,o=grid
GlueServiceEndpoint: httpg://srm01.ncg.ingrid.pt:8444/srm/managerv2

In a similar way, by just changing the value of GlueServiceType, you can retrieve the endpoint URLs of other services.

An alternative way for retrieving the GlueServiceEndpoint URL is using the GLUE2 information browser provided by VAPOR: select your NGI, then your site and hence the Storage service; click on the endpoint details button for finding the URL associated to the SRM interface.

Filling the information in

URLs information are completely missing

Editing the services information

Site overview

This is the home page regarding your site. You need to fill in the URL information.

Click on a service for displaying its page (e.g. the CREAM-CE).

Editing a service

Click on the EDIT button in the top right corner

Adding a Service URL

fill in the Service URL field with the queue URL

Reviewing the site

Now the CREAM-CE service endpoint contains the required queue information.

Proceed in a similar way for the other services.

Additional endpoints information

In case you need to register an additional endpoint for a service, go on the service summary page and add the proper information. In the example below it is shown the case of a computing element.

Service summary page

This is the service summary page.

You need to click on the Add endpoint button for registering additional endpoint URLs.

Adding an endpoint

Fill in the proper information and don’t forget to select the “Monitored” flag for making Nagios to detect the new endpoint.

Reviewing the endpoint description

The summary page of the endpoint just added should look like this one.

Reviewing the service description

And this is the summary page of the service reporting the information about all its endpoints registered: the first one in the Grid Information section and the additional ones in the Service Endpoints section.

Examples

webdav

In order to properly monitor your webdav endpoint:

you should register a new service endpoint with the webdav service type, separated from the SRM one;
the endpoint URL information used for monitoring purposes should be set in the extension properties section. Create the following:
- Name: ARGO_WEBDAV_OPS_URL
- Value: webdav URL containing also the VO ops folder, for example: https://darkstorm.cnaf.infn.it:8443/webdav/ops or https://hepgrid11.ph.liv.ac.uk/dpm/ph.liv.ac.uk/home/ops/
  - it corresponds to the value of GLUE2 attribute GLUE2EndpointURL (containing the used port and without the VO folder);
verify that the webdav URL (for example: https://darkstorm.cnaf.infn.it:8443/webdav) is properly accessible.

EOS and XrootD service endpoints

The EOS service endpoints expose an XrootD interface, so in order to properly monitor them, even in case you provide a plain XrootD endpoint, please do the following:

you should register a new service endpoint with the XrootD service type;
the endpoint URL information used for monitoring purposes should be set in the extension properties section. Create the following:
- Name: ARGO_XROOTD_OPS_URL
- Value: XRootD base SURL to test (the path where ops VO has write access), for example: root://eosatlas.cern.ch//eos/atlas/opstest/egi/, root://recas-se-01.cs.infn.it:1094/dpm/cs.infn.it/home/ops/, root://dcache-atlas-xrootd-ops.desy.de:2811/pnfs/desy.de/ops or similar). Pay attention to the port configured for the interface.

GridFTP

In order to properly monitor your gridftp endpoint for ops VO

register a new service endpoint, associating the storage element hostname to the service type globus-GRIDFTP, with the “production” flag disabled;
in the “Extension Properties” section of the service endpoint page, fill in the following fields:
- Name: SE_PATH
- Value: /dpm/ui.savba.sk/home/ops (this is an example, set the proper path)
check if the tests are OK (it might take some hours for detecting the new service endpoint) and then switch the production flag to “yes”

SURL value for SRM

The SURL value needed by the SRM monitoring probes is the following structure:

srm://<hostname>:<port>/srm/managerv2?SFN=<GlueSAPath or GlueVOInfoPath>

For example:

srm://ccsrm.in2p3.fr:8443/srm/managerv2?SFN=/pnfs/in2p3.fr/data/dteam/

As explained in previous sections, you can retrieve the port number from the GlueServiceEndpoint URL information.
If your SE provides GlueSAPath information, use that. To retrieve it:

$ ldapsearch -x -LLL -H <ldap://sbdii01.ncg.ingrid.pt:2170> \
 -b "mds-vo-name=NCG-INGRID-PT,o=grid" \
 '(&(objectClass=GlueSA)(GlueSAAccessControlBaseRule=VO:ops))' \
 GlueSAPath GlueChunkKey

dn: GlueSALocalID=opsdisk:replica:online,GlueSEUniqueID=srm01.ncg.ingrid.pt,Mds-Vo-name=NCG-INGRID-PT,o=grid
GlueChunkKey: GlueSEUniqueID=srm01.ncg.ingrid.pt
GlueSAPath: /gstore/t2others/ops

if your SE doesn’t provide GlueSAPath information, use instead the GlueVOInfoPath one:

$ ldapsearch -x -LLL -H <ldap://ntugrid5.phys.ntu.edu.tw:2170> \
 -b "Mds-Vo-name=TW-NTU-HEP,o=grid" \
 (&(objectClass=GlueVOInfo)(GlueVOInfoAccessControlBaseRule=VO:ops)) \
 GlueVOInfoLocalID GlueChunkKey

dn: GlueVOInfoLocalID=ops:SRR,GlueSALocalID=SRR:SR:replica:*****,GlueSEUniqueID=ntugrid6.phys.ntu.edu.tw,Mds-Vo-name=TW-NTU-HEP,o=grid
GlueVOInfoPath: /dpm/phys.ntu.edu.tw/home/ops
GlueChunkKey: GlueSALocalID=SRR:SR:replica:*****
GlueChunkKey: GlueSEUniqueID=ntugrid6.phys.ntu.edu.tw
GlueVOInfoLocalID: ops:SRR

dn: GlueVOInfoLocalID=ops:data01,GlueSALocalID=data01:replica:online,GlueSEUniqueID=ntugrid6.phys.ntu.edu.tw,Mds-Vo-name=TW-NTU-HEP,o=grid
GlueVOInfoPath: /dpm/phys.ntu.edu.tw/home/ops
GlueChunkKey: GlueSALocalID=data01:replica:online
GlueChunkKey: GlueSEUniqueID=ntugrid6.phys.ntu.edu.tw
GlueVOInfoLocalID: ops:data01

Pay attention to use the storage path for the ops VO
On GOCDB, in the “Extension Properties” section of the SRM service endpoint page, fill in the following fields:
- Name: SURL
- Value: the actual SURL value, for example: srm://srm01.ncg.ingrid.pt:8444/srm/managerv2?SFN=/gstore/t2others/ops

Internal: Downtimes

Mon, 01 Jan 0001 00:00:00 +0000

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). The Configuration Database 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
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 in the Configuration Database where downtimes are listed:

Active & Imminent, linked from the main menu, that allows users to see currently active downtimes and downtimes planned in the coming weeks.
Downtime Calendar, linked from the main menu, that allows users to view and filter all downtimes.
Site details, where all the downtimes associated to the site are listed
Service endpoint details, where all the downtimes associated to the service endpoint are listed.
Service group details, where all the downtimes associated to the service group are listed.

Each downtime has its own page providing details, accessible by clicking on the Downtime Id link or similar in downtime listing pages.

Subscribing to downtimes

The EGI Operations Portal provides a publicly-accessible page allowing to view and filter downtimes: Operations Portal.

Authenticated users can subscribe to downtimes affecting sites selected using a filter. The downtimes notifications can be sent by email, RSS and iCal, allowing to easily integrate with your calendar.

Adding downtimes

Provided you have proper permissions (check the permissions matrix section), you can add a downtime by clicking on the Add 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 or using the Site Timezone.
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 Service intervention management 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.
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

Limitation rules to downtime extensions are enforced as follows:

Scheduled downtimes due to start in 24 hours cannot be edited in any way, nor deleted.
Other downtimes that have not yet started can be edit and deleted.
- They can be shortened or moved, i.e. They can be edited such that:
  - Both start and end time are still in the future
  - The duration remains the same or is decreased
Ongoing downtimes can not be deleted.
A downtime cannot be edited once it has finished, nor can a new downtime be added more than 48 hours into the past.

If for any reason a downtime already declared needs to be extended, the procedure is to add another adjacent downtime, before or after.

Internal: Extension Properties

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

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.
Selected methods in the Configuration Database API 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(link to old EGI Wiki)
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 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.
Keys must be unique for a given site, service, or service endpoint, or service group.

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 (link to old EGI Wiki)
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 omitted 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:
- ((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:
- ((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 version 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=)

Standard Extension Properties

HostDN

For EGI Services, the Standard Extension property “HostDN” has been defined to allow the fetching the DNs of multiple hosts behind a load balanced service from the endpoint properties of a single GOCDB Service, rather than creating multiple GOCDB Services with different host DNs.

Recommended Use

To supply multiple or alternate DN(s) for a service, for example of the multiple hosts supporting a single service entry, the Service Extension Property (hereafter Ext) “HostDN” SHOULD be used. If Ext “HostDN” is present it MUST contain one or more x.509 DN values. Multiple values MUST be delimited by enclosing each within “<>” characters. If Ext “HostDN” is present, the Service “Host DN” SHOULD contain the x.509 SubjectAltName used in the X509 certificate(s) presented by the hosts identified by the Ext “HostDN” values.

Internal: Managing NGIs entities

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

An NGI forms a grouping of Sites in EGI Configuration Database. The Configuration Database 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:

PROC02: Operations Centre creation

Integration of the new group in the EGI Configuration Database is part of the procedure but has to be done by the Configuration Database 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.

Internal: NGI Core Services

Mon, 01 Jan 0001 00:00:00 +0000

NGI Core Services

NGIs can register a number of ‘NGI-Core’ services in the Configuration Database. 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:

Be flagged as ‘Production’ (see Production Flag)
Not be flagged as ‘Beta’ (see Beta Flag)
Monitored flag set to true (see Monitored Flag)
Be hosted under a ‘NGI’ scoped Site that has a certification status of ‘Certified’

Required Service Types

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

emi.ARGUS (Mandatory) (NGI ARGUS)
Top-BDII (Mandatory)

Other Mandatory services, depending on middleware deployed by sites under NGI responsibility, are the following:

MyProxy
VOMS

NGIs should also register their custom core services like accounting, helpdesk if provided.

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. The list of existing Service Groups is available on GOCDB.

Internal: Scoping

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Scope tags are used to group 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 Configuration Database 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 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 checkbox 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 Configuration Database 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).
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.
You can submit your request for new scope tags via EGI Helpdesk to the “Configuration and Topology Database (GOCDB)” support unit.

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 Configuration Database 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 Configuration Database admins with details of the approval (e.g. link to an EGI Helpdesk ticket that approves the tag assignment).
Users with a suitable role over a Site, or a Site’s parent NGI can remove reserved scope tags from their Site and its child Services. As part of maintaining their Site information in GOCDB, Users should remove reserved scope tags from their Sites and/or their Services when they cease to be relevant.

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 the EGI Configuration Database.

GreenDIGIT Reserved Tag

Tag for resources that contribute to the GreenDIGIT project. To request this tag, please contact EGI Operations.

WLCG Reserved Tags

A number of reserved scope tags have been defined for the WLCG:
- The VO.tierN tags should be requested for WLCG sites that are defined in CRIC. To request one of these scope tags, first raise a ticket against the relevant VO support unit for confirmation, then reassign the ticket to GOCDB.
- The wlcg tag is a generic catch-all tag for sites/services to gain an overall view of the WLCG infrastructure. It will be applied along with the VO.tierN tags

SLA Reserved Tag

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

EOSCCore Tag

Tag for resources that contribute to core services of the EOSC. To request this tag, please raise an EGI Helpdesk ticket against the Operations SU.

EGICore Tag

Tag for resources that are part of the EGI Core services. To request this tag, please raise an EGI Helpdesk ticket against the Operations SU.

Internal: Service Entities

Mon, 01 Jan 0001 00:00:00 +0000

Definition

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 ServiceTypes below)
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.

Example

The 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
myhost.domain.org	CE
myhost.domain.org	UI
myhost.domain.org	unicore6.Gateway

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

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 ServiceType and URL alone.

For example: The Service entity goc.egi.eu (of ServiceType egi.GOCDB) defines the following Service Endpoint entities:

Name	URL	Interface Name
ProductionPortalInstance	https://goc.egi.eu/portal	egi.GOCDB.Portal
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).

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.

To supply multiple or alternate DN(s) for a service, for example of the multiple hosts supporting a single Service entity, see standard 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 ServiceType 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 entities won’t be tested.

Usage of PRODUCTION and MONITORED flags for EGI Service entities

All production Service entities MUST be monitored (except for emi.ARGUS and VOMS ServiceTypes).

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 ServiceType associated 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 CRITICAL failure.
Monitoring tests for non-production Service entities 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”.

Internal: Service groups

Mon, 01 Jan 0001 00:00:00 +0000

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 Administrator’ 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 members can be listed using the get_service_group_role PI method.
PI doc:
- get_service_group(link to old EGI Wiki)
- get_service_group_role(link to old EGI Wiki)
If you have any further use-cases or suggestions, please submit a GGUS ticket.

Internal: Service Types

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

In the EGI Configuration Database, a service type is a technology used to provide a service. Each service endpoint 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 and cloud 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 therefore 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.

Service Type List

To request a new service type, please submit a request for a new service type (see the section “Adding a new service type”).

In the following section there is the list of “middleware agnostic” service types. You can obtain the whole list of service types by browsing Poem, or by launching the following query to the GOCDBPI interface:

get_service_type

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
(deprecated) 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
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 Check-in SAML interface. Enables federated access to EGI services and resources using Security Assertion Markup Language (SAML). Provided by GRNET.
egi.aai.oidc: EGI Check-in OpenID Connect interface. Enables federated access to EGI services and resources using OpenID Connect (OIDC). Provided by GRNET.
egi.aai.tts: EGI Check-in token translation service. Enables the translation between different authentication and authorisation protocols. Provided by GRNET.

Adding new services types

Please feel free to make a request for a new service type. All new service type requests need to be assessed by EGI via lightweight review process (by EGI OMB and EGI Operations) so that only suitable types are added, and to prevent duplication.

You can submit your request via EGI Helpdesk to the “Configuration and Topology Database (GOCDB)” support unit.

Please specify the following information as part of your request:

name of service type (lowercase):
high-level description of the service functionality (255 characters max):
project/community/organization maintaining the software:
scale of deployment (number of instances and by which organizations):
contact point (name/email address):

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

Internal: Sites

Mon, 01 Jan 0001 00:00:00 +0000

Definition

A site (also known as a Resource Centre) is a grouping of grid resources collating multiple Service Endpoints (SEs). Downtimes 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 email for a fast response time in case of urgent problem
- Alarm email 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 related 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 permissions, 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 next section 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 the permissions associated to the roles in the related section.
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 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 suspended 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 the EGI Federation Procedures:

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

Internal: Users and roles

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

In the sub-pages there is an explanation over the EGI Configuration Database user accounts, how to manage them, and the roles defined.

Internal: Service registration requirements

Mon, 01 Jan 0001 00:00:00 +0000

Information to provide when registering a new service (the fields marked with an asterisk are mandatory):

Hosting Site * (select the appropriate RC under which you are registering the service)
Service Type * (select the appropriate service type)
Service URL (Alphanumeric and $-_.+!*’(),:)
Hostname * (valid FQDN format)
Host IP a.b.c.d
Host IPv6 (0000:0000:0000:0000:0000:0000:0000:0000[/int]) (optional [/int] range)
Host DN (/C=…/OU=…/…)
Description * (Alphanumeric and basic punctuation)
Host Operating System (Alphanumeric and basic punctuation)
Host Architecture (Alphanumeric and basic punctuation)
Is it a beta service (formerly PPS service)? Y/N
Is this service in production? Y/N
Is this service monitored? Y/N
Contact email * (valid email format)

Scope Tags

✓ Optional Tags (At least 1 optional tags must be selected): EGI Local FedCloud
✓ Reserved Tags Inheritable from Parent Site: none
✓ Reserved Tags Directly Assigned (WARNING - If deselected you will not be able to reselect the tag - it will be moved to the ‘Protected Reserved Tags’ list): none
✗ Protected Reserved Tags (Can only be assigned on request): alice atlas cms elixir lhcb tier1 tier2 wlcg

Internal: Adding a new project

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

GOCDB, the software powering the EGI Configuration Database, 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 EGI Configuration Database admins and EGI Operations to discuss the options available.

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 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 new resources would still be subject to the rules of the existing project, such as site certification status changes and project controlled 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 of other projects, for example, allowing the project to control its site certification status changes and project controlled user 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

Internal: API

Mon, 01 Jan 0001 00:00:00 +0000

Note

Exhaustive documentation of the API for the GOCDB service, powering the EGI Configuration Database, is available on the dedicated GOCDB API documentation site.

The GOCDB Programmatic Interface (PI) is available under /gocdbpi.

API components

The GOCDB PI has two main components:

The Read API
The Write API

The Read API provides programmatic access to the data. Access to some information (security/critical, personal details, otherwise sensitive information) is restricted, more details are available in the section about data protection levels.

The Write API provides limited functionality to add, update, and delete entities. Access is restricted, more details can be found in the section about authentication and authorisation.

Using the Read API

Querying

API calls can be tested in a browser or done from the command-line interface, using curl.

Below are some examples, including methods with different data protection levels.

API calls starting with https://goc.egi.eu/gocdbpi/private require the client to present a valid credential.

Public calls, no authentication required:
- Retrieving all service endpoints
- Collecting information about endpoints under the EGI and FedCloud scopes
Private calls, with authentication required:

Extracting content

It is possible to filter content using xpath. Download information about endpoints under the EGI and FedCloud scopes as egi_fedcloud_service_endpoints.xml.

# Extracting endpoints in production
$ xpath -q -e "//SERVICE_ENDPOINT[IN_PRODUCTION='Y']/HOSTNAME/text()" \
 egi_fedcloud_service_endpoints.xml | sort | uniq

Using an X.509 client certificate to authenticate from the CLI

Querying information about a specific site using CURL, and authenticating with an X.509 client certificate.

$ curl -v --cert ~/.globus/usercert.pem --key ~/.globus/userkey.pem \
 'https://goc.egi.eu/gocdbpi/private/?method=get_site&sitename=CESGA'

Querying using python

Looking for FedCloud endpoints

See python script from cloud-info-provider repository.

Using the Write API

Examples of using the Write API can be found on the GOCDB PI site.

Internal: FAQ

Mon, 01 Jan 0001 00:00:00 +0000

I have lost access to my account, what should I do?

If you were registered but are not recognised anymore (e.g. because your certificate DN changed), do not register again!

Instead, follow the steps Lost access to your Configuration Database account section.

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 EGI Configuration Database (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.

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 first one finishes. Please refer 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 the Configuration Database 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 Configuration Database 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 the backend to retrieve information for my project. What can I do?

Accessing the backend through another way than the Configuration Database web interface is out of the scope of this documentation. Please refer to the technical documentation instead, which is available from GOCDB Documentation.