wiki:dCacheWithEMIR
Last modified 6 years ago Last modified on 11/28/12 12:27:47

Publish dCache Information to EMIR

EMIR (short for EMI Registry) is a hierarchical Information System to easily discover registered services. It consists of two components: EMIR and EMIR-SERP. Official documentation can be found here

  • EMIR-SERP stands for EMIR Service Endpoint Record Publisher. It can be configured to publish information about several endpoints to a EMIR Server. It depends on python, python-ldap and python-simplejson
  • EMIR is the EMI Registry Server. It publishes the information that it got from the connected SERPs as JSON. It depends on Java (version > 1.6) and MongoDB (Version > 2.0.1)

To set up EMIR for dCache configure EMIR as described in the next section. We will first use most defaults and simple options to get the system up and running and afterwards explain some options that might be useful to tweak for dCache. All available options are also described on the EMIR homepage and within the the configuration files.

EMIR

First configure your local EMIR:

Set emir.address to the URL your EMIR Server will be accessed as. We will first use 'http' and most default values for simplicity. E.g.,

emir.address=http://emir.example.org:9126

and the configuration to use with MongoDB: E.g.,

emir.mongodb.hostName=localhost
emir.mongodb.port=27017
emir.mongodb.dbName=emiregistrysecure
emir.mongodb.collectionName=services

If you want to publish your collected SERs to a parent server set it like this: E.g.,

emir.parentAddress=http://emirparent.parent-example.org:9126/services

EMIR-SERP

The configuration of the EMIR-SERP is devided in sections. The first section contains the basic configuration and is called

[emir-serp]

it contains the url of the EMIR Server to publish the service records to:

url=http://emir.example.org:9126

There are two more mandatory options, namely period and validity that need to be set:

period=1
validity=1

period defines the time in hours of registration/update messages and validity is the time in hours of how long an registration entry is considered valid.

We will leave the remaining options in this section at their defaults for now.

Then for each service you want collect informations about you need an own section For dCache there are different ways how to define the service. The first way is to directly use dCache's BDII (which as far as my experiments go, still does not fully work, but as it seems to be the best way in principle) E.g.,

[dCacheServiceBDII]
resource_bdii_url = ldap://bdii.example.org:2170

The second way is to periodically (e.g., hourly) call ginfo from cron. E.g.,

#!/bin/sh
/usr/bin/ginfo --host bdii.example.org:2170 --emi > /var/cache/emir/services/example-org.json

and then use this file in a emir-serp service section:

[dCacheServiceFILE]
Service_Endpoint_URL = http://xen-ep-emi-tb-se-6.desy.de:2288
json_file_location = /var/cache/emir/services/xen-ep-emi-tb-se-6

Known Issues

  • Service_Endpoint_URL property has to be set in emir-serp.ini even if the endpoint is defined in the file or given from bdii.
  • ginfo generates the properties:
    • Service_Endpoint_Interface_Name
    • Service_Endpoint_Interface_Version
    but in the logs there are warnings about missing mandatory properties
    • Service_Endpoint_InterfaceName
    • Service_Endpoint_InterfaceVersion
    • Service_Name - this seems not to be generated by ginfo at all, but it may be set in the service section in emir-serp.ini, although it seems not to be used in the data published.