INFSO-RI Enabling Grids for E-sciencE gLite C++ Configurator Practical experience gLite Configuration Meeting, March 1, 2005 Peter Kunszt on behalf of the JRA1-DM Cluster

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, Contents An Example Improvements Food for Thought

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, 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

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, 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 Params; where Param basically is the configuration parameter name (it has a single getName() method of relevance) THIS IS AN EXAMPLE

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, 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;

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, 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; } }

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, 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 ((*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 ((*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 ((*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; }

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, 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()

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, Configuration Template File The GLite Transfer Command Line Interface provides a few executables which can be used on the command line to interact with the File Placement Service and the Data Scheduler. The endpoint of the FPS service where the Glite FPS Server is running The SRM endpoint. This needs to be the SRM associated with the FPS given in the FPSendpoint parameter When generating SURLs, the endpoint of the SRM is used and this prefix may be added if necessary on some systems. There are several SURL autogeneration patterns: flat, date, day, lfn. flat

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, Service Configurator –Configure Log4Cpp (Using Log4J Property File) –Load all the components dynamically (Configuration File) –Configure all the Components –Notify the Components to start/stop –Handle Reconfiguration GLite Data Service a.k.a. Daemon launcher –Spawn a daemon process –Instantiate ServiceConfigurator and call it –Handle control signals –Monitor the daemon process GLite Data glite_data_config library –C library –Instantiate and manage ServiceConfigurator –Can be used to configure libraries or application that doesn’t need to run as daemon or services Independent from GLite I/O !

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, Shameless self advertisement Works very well also for dynamic library loading –There is a 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:

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, 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

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, 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 Happy Sysadmin Happy Developers

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, 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

Enabling Grids for E-sciencE INFSO-RI gLite Configuration – March 1, What would we do? Just ask..