Difference between revisions of "DIS-BDII-Client"

From Gcube Wiki
Jump to: navigation, search
(Usage Example)
(Usage Example)
Line 177: Line 177:
  
  
There is the need of a manual configuration step after deployment phase. The Service JNDI file contains two parameters that have to be filled:
+
There is the need of a manual configuration step after deployment phase. The Service JNDI file contains three parameters that have to be filled:
 
*bdiiHost: the BDII server url to interact with.
 
*bdiiHost: the BDII server url to interact with.
 
*bdiiPort: the BDII server port to interact with.
 
*bdiiPort: the BDII server port to interact with.
 +
*defaultVO: specifies the VO to use to filter the queries. The * value means no queries filtering.
  
 
--[[User:Andrea|Andrea]] 18:10, 30 May 2007 (EEST)
 
--[[User:Andrea|Andrea]] 18:10, 30 May 2007 (EEST)

Revision as of 09:20, 27 August 2007

Introduction

This Service replaces the DIS-R-GMA-Client Service implemented in the DILIGENT Alpha release: the EGEE infrastructure has definitely choosen the BDII Server as default gLite Information System, and there was not need to maintain a R-GMA Server harvester active in the DILIGENT Infrastructure. This service is in charge to harvest resources information from the gLite BDII Server it has been configured to interact with. This information is related to grid resources (CEs, SEs, I/O Servers, etc.) belonging to each gLite based grid infrastructure the DILIGENT system is interacting with. Then, the gathered information is manipulated in order to be compliant with the schema adopted in DILIGENT and published as gLite Resource using the DIS-Registry (static information based on Glue schema specification v1.2) or as WS-Resource Properties on the local DIS-IP where the DIS-BDII is deployed via the Aggregator Framework support.

Implementation Overview

The only public operations implemented by the DISBDIIClientFactoryService are

createResource(Type)

It allows creating WS-Resources of type DISBDIIClientService/CE/SE, returning a CreateResourceResponse object that contains the EPR of the new WS-Resource created.

The standard GT4 providers provide all the operations offered by the DISBDIIClientService, DISBDIICllientSE and DISBDIIClientCE services:

  • SetResourceProperty;
  • GetResourceProperty.


queryForProfiles (QueryForProfiles profiles)

Start harvesting from the BDII Server instance the service has been configure to interact, and creates Site/CE/SE/Service gLiteResource profiles contacting the DIS-Registry


queryForPropertes (QueryForProperties properties)

Start harvesting from the BDII Server instance the service has been configure to interact, and *creates CE/SE/Service WS-Resource Properties publish them on the DIS.

The gLiteInfoProvider implements a thread acting as a client of the service. The tasks it performs are:

  • contacting gLite BDII server using JLdap client API and retrieving tuples belonging to GLUEService table;
  • creating for every gLite service, SE and CE the corresponding DISBDIIClientService/CE/SE WS-Resource;
  • invoking the appropriate DIS-Registry operations to register gLite Resource profiles.
  • maintaining persistent information about gLiteResources locally (EPR of the resource). Thus, it can periodically update information about the Resources or add some Resources that were not on the BDII Server before. This is also important when some gLite Services/SEs/CEs disappear from the BDII server: the corresponding WS-Resource is automatically destroyed.The state maintains also the IDs of the DILIGENT gLite resource profiles: the information about the IDs is collected in order to remove them if the service restarts or is redeployed.

The three type of WS-Resource register there WS-Resource-Properties:

  • gLiteServiceResource
    • uniqueIDRP: unique ID of the gLite Service;
    • statusRP: status info for gLite Service;
    • statusInfoRP: other status information for gLite Services;
  • gLiteCEResource
    • uniqueIDRP;
    • runningJobsRP;
    • waitingJobsRP;
    • totalJobsRP;
    • estimatedResponseTimeRP;
    • worstResponseTimeRP;
    • freeJobsSlotRP;
    • maxWallClockTimeRP;
    • maxCPUTimeRP;
    • maxTotalJobsRP;
    • maxRunningJobsRP;
    • assignedJobSlotsRP;
    • priorityRP;
  • gLiteSEResource
    • UniqueIDRP;
    • UsedSpaceRP ;
    • AvailableSpaceRP ;
    • CurrenIOLoadRP ;

All these WS-ResourceProperties are also exposed as Topics and registered to the DIS-Broker exploiting the mechanism of subscription brokering.

Dependencies

The service dependencies towards other DILIGENT component are:

  • DIS-Registry stubs;
  • NAL library;
  • DIS-IP library;
  • DILIGENTProvider provider;
  • DIS-Broker stubs;
  • ProfileManager library
  • Delegation Service
  • DVOS Common library
  • DVOS Authentication API library
  • DIS-Utiil library
  • DIS-HLSClient library

The Service depends on third party library:

  • Jaxb 2.0
  • JLdap client API library

--Andrea 17:37, 30 May 2007 (EEST)

Usage Example

The service needs two template query files to select the Ldap query to perform towards the BDII Server. In particular the bdiQueryProfile.xml contains the query needed to create SE/CE/Site/Service Profile and the bdiiQueryProperties.xml that contains the query needed to create BDII WS-Resource.

bdiiQueryProfile.xml:


  <QUERY>
    <ID>siteProfileQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueSite)</FILTER>
  </QUERY>
   <QUERY>
    <ID>serviceForSiteQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueService)</FILTER>
  </QUERY>
  <QUERY>
    <ID>glueCESEBindQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueCESEBind)</FILTER>
  </QUERY>
   <QUERY>
    <ID>glueServiceAssociationQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueServiceAssociation)</FILTER>
  </QUERY>
 <QUERY>
    <ID>serviceProfileQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueService)</FILTER>
  </QUERY>
<QUERY>
    <ID>ceProfileQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueCE)</FILTER>
  </QUERY>
<QUERY>
    <ID>glueClusterQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueCluster)</FILTER>
  </QUERY>
<QUERY>
    <ID>glueSubClusterQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueSubCluster)</FILTER>
  </QUERY>
  <QUERY>
    <ID>glueLocationQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueLocation)</FILTER>
  </QUERY>
  <QUERY>
    <ID>seProfileQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueSE)</FILTER>
  </QUERY>
  <QUERY>
    <ID>glueSAQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueSA)</FILTER>
  </QUERY>
  <QUERY>
    <ID>glueSEAccessProtocolQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueSEAccessProtocol)</FILTER>
  </QUERY>
   <QUERY>
    <ID>glueSEControlProtocolQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueSEControlProtocol)</FILTER>
  </QUERY>


bdiiQueryProperties.xml:


  <QUERY>
    <ID>serviceQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueService)</FILTER>
  </QUERY>
  <QUERY>
    <ID>ceQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueCE)</FILTER>
  </QUERY>
   <QUERY>
    <ID>seQuery</ID>
    <BASEDN>mds-vo-name=local,o=grid</BASEDN>
    <FILTER>(objectClass=GlueSE)</FILTER>
  </QUERY>


There is the need of a manual configuration step after deployment phase. The Service JNDI file contains three parameters that have to be filled:

  • bdiiHost: the BDII server url to interact with.
  • bdiiPort: the BDII server port to interact with.
  • defaultVO: specifies the VO to use to filter the queries. The * value means no queries filtering.

--Andrea 18:10, 30 May 2007 (EEST)