infso-ri-508833 enabling grids for e-science glite c++ configurator practical experience glite...

INFSO-RI-508833

Enabling Grids for E-sciencE

www.eu-egee.org

gLite C++ ConfiguratorPractical experience

gLite Configuration Meeting, March 1, 2005Peter Kunszt on behalf of the JRA1-DM Cluster

gLite Configuration – March 1, 2005 2


INFSO-RI-508833

Contents

• An Example• Improvements• Food for Thought



INFSO-RI-508833

An Example (Developer’s View)

• Configuration is stored in an XML file• Each service component has its own block of config

data in this file• Each service to be configured needs to implement a C+

+ ComponentConfigurator class by extending

glite::config::ComponentConfigurator

• The configuration values are always strings• The configuration names are arbitrary but should be

descriptive



INFSO-RI-508833

An Example cont.

• Example: Transfer CLI configuration as it is today.• Basic methods (from TransferConfig.h):

class TransferConfig: public glite::config::ComponentConfiguration {

static const char * NAME; // the component name virtual int init(const Params& params); // initialize (only this is used) virtual int config(const Params& params); // configure (just return 0) virtual int start(); // start “ virtual int stop(); // stop “ virtual int fini(); // finalize “

static TransferConfig * instance(); // get singleton static void finalize(); // finalize singleton

• Params is defined as: typedef std::map<std::string, Param *> Params;

where Param basically is the configuration parameter name (it has a single getName() method of relevance)

THIS IS AN EXAMPLE



INFSO-RI-508833

Example cont’d• Methods returning configuration properties:

const char * getEndpoint() const { return m_endpoint.c_str();}

const char * getSURLprefix() const { return m_surl_prefix.c_str();}

const char * getSrmEndpoint() const { return m_srmEndpoint.c_str();}

const char * getSURLpattern() const { return m_surl_pattern.c_str();}

• Private fields:

static TransferConfig * s_instance;

std::string m_endpoint;

std::string m_srmEndpoint;

std::string m_surl_prefix;

std::string m_surl_pattern;



INFSO-RI-508833

Example Implementation cont’d• Constants

const char * GLITE_TRANSFER_CLI_NAME = "transfer-cli"; const char * ENDPOINT_PROPERTY_NAME = "FPSendpoint"; const char * SRM_ENDPOINT_PROPERTY_NAME = "SRMendpoint"; const char * SURL_PREFIX_PROPERTY_NAME = "SURLprefix"; const char * SURL_PATTERN_PROPERTY_NAME = "SURLpattern"; const char * TransferConfig::NAME = GLITE_TRANSFER_CLI_NAME;

• Each Configuration Component class needs to have a creation and destruction method:extern "C" { ComponentConfiguration * create_glite_component(){ return TransferConfig::instance(); } void destroy_glite_component(ComponentConfiguration * component){ TransferConfig::finalize(); } } // End extern "C"

• The singleton implementation is trivial

TransferConfig* TransferConfig::s_instance = 0; TransferConfig* TransferConfig::instance(){ if(0 == s_instance){ s_instance = new TransferConfig(); } return s_instance;}void TransferConfig::finalize(){ if(0 != s_instance){ delete s_instance; } }



INFSO-RI-508833

Example Implementation• Creation and Initialization

TransferConfig::TransferConfig():ComponentConfiguration(NAME);

int TransferConfig::init(const Params& params){ Params::const_iterator it; // Get Endpoint if((it = params.find(ENDPOINT_PROPERTY_NAME)) != params.end()){ ParamValue * pv = dynamic_cast<ParamValue *>((*it).second); if(0 == pv){ return -1; } // ERROR m_endpoint = pv->getValue(); } else { return -1; } // ERROR - Mandatory

if((it = params.find(SRM_ENDPOINT_PROPERTY_NAME)) != params.end()){ ParamValue * pv = dynamic_cast<ParamValue *>((*it).second); if(0 == pv){ return -1; } // ERROR m_srmEndpoint = pv->getValue(); } else { return -1; } // ERROR - Mandatory

if((it = params.find(SURL_PREFIX_PROPERTY_NAME)) != params.end()){ ParamValue * pv = dynamic_cast<ParamValue *>((*it).second); if(0 == pv){ return -1; } // ERROR m_surl_prefix = pv->getValue(); } else { return -1; } // ERROR - Mandatory

if((it = params.find(SURL_PATTERN_PROPERTY_NAME)) != params.end()){ if(0 == pv){ return -1; } // ERROR m_surl_pattern = pv->getValue(); } else { m_surl_pattern = “default”; } // DEFAULT VALUE

return 0; }



INFSO-RI-508833

Usage

• In the main code, the configuration needs to be registered and initialized:

glite_config_register( TransferConfig::instance() );glite_config_initialize( TransferConfig::NAME );

• The fields can be used simply by accessing the getter methods like

const char * ep = TransferConfig::instance()->getEndpoint()



INFSO-RI-508833

Configuration Template File

<service name="glite-data-transfer-cli"><components><component name="transfer-cli"> <config-template> <description>The GLite Transfer Command Line Interface provides a few executableswhich can be used on the command line to interact with the File Placement Service and the Data Scheduler.</description> <init> <param name="FPSendpoint" mandatory="true" type="string"> <description>The endpoint of the FPS service where the Glite FPS Server is running</description> <value></value> </param> <param name="SRMendpoint" mandatory="true" type="string"> <description>The SRM endpoint. This needs to be the SRM associated with the FPS given in the FPSendpoint parameter</description> <value></value> </param> <param name="SURLprefix" mandatory="false" type="string"> <description>When generating SURLs, the endpoint of the SRM is used and this prefix may beadded if necessary on some systems.</description> <value></value> </param> <param name="SURLpattern" mandatory="false" type="string"> <description>There are several SURL autogeneration patterns: flat, date, day, lfn.</description> <value>flat</value> </param> </init> </config-template></component>

</components></service>



INFSO-RI-508833

Shameless self advertisement

• Works very well also for dynamic library loading – There is a <lib> tag which can be set to the name of the dynamic

library to be loaded– The register method need not be called in this case since the

library is scanned for the create_glite_component method– For an example see glite-io

• This has been in use since ‘forever’ (mid-August 2004)• Well tested• Simple• It’s working well for us• Nevertheless we know how to improve it:



INFSO-RI-508833

Possible Improvements• Right now the XML files contain ‘static’ values (you

need to edit the file to reconfigure the service) – extend to info system– Parameters might be configured to be retrieved from the

information services or service discovery (for example supporting a service-discovery tag in addition to the value tag)

• Support for extended types: list, map, struct,..– Makes multi-VO support possible



INFSO-RI-508833

Improvements: Food for Thought

• Sysadmin view (top-down) vs. Developer (bottom-up)

Simple site configuration

Simple component

configuration

Component

Simple component

configuration

Component

Simple component

configuration

Component

Magic

Magic Magic Magic

Happy Sysadmin

Happy Developers



INFSO-RI-508833

What is ‘Magic’?

• Requirements:– Sysadmins want a single point of entry controlling all static and

dynamic configuration data– Developers want their modules to be usable in a standalone way

which is necessary for testing and debugging without an extra heavy layer on top

• ‘Magic’ design needs to take into account– Bootstrapping: when the component is new and has no config

yet– Local configuration caching: A config file which can be used by

the system in standalone mode– Communication between the component and the sysadmin

tooling for dynamic updates– Possible legacy components with ‘incompatible’ configuration



INFSO-RI-508833

What would we do?

• Just ask..

infso-ri-508833 enabling grids for e-science glite c++ configurator practical experience glite...

Documents