Configuration for gLite

1. Configuration for gLite Joachim Flammer on behalf of JRA1 integration team

2. Content • Idea of this presentation • key aspects of configuration issues • where do we stand in terms of integration team • next (possible) steps • base for discussion • General aspects • Configuration aspects split up in four areas • Installation • Storing the values • Accessing the values • Changing the values • Corporate approach for configuration • The system has to be manageable • User friendliness: keep the end user in mind • Modular approach • Separate areas • Allow for changes later – new technologies etc. • Different plug-ins Configuration

3. Installation • Key aspects: • Support of a heterogeneous environment • Multi-platform environment (Linux, MS Windows) • Multiple packaging systems (RPM, tgz, MSI, …) • Compatible with standard installation tools (apt, yum, MS Installer, etc.) and installation/configuration systems (Quattor, SMS, etc.) • Support of user in installation process • Automatic download of necessary components and dependencies • Common handling of service startup Configuration

4. Installation • Present status: • Service based installation: • main building block is service: set of components providing a given functionality (e.g. clients are also considered as services) • Service description file: service is described using an XML file that contains allthe necessary information about the service (components, dependencies ..) • All packaging and installation related scripts like .spec, glite installation scripts, quattor templates are derived from the service description file • Deployment units: nodes • Node consist of the set of installed services and (possibly) of some additional packages. • two configuration types: • Post-install configuration • Environment setup needed after the installation of the service create the working environment for the service (creation of DBs, …) • Configuration is done via python scripts • Service configuration • Configuration of the service at startup and at run-time • Configuration is heterogeneously done by each service individually • global gLite init.d script • Standard interface for managing start/stop of gLite services Configuration

5. Installation • Next (possible) steps: • Clear separation between post-installation and service configuration • Usage of common configuration files directly • Shrink post-installation configuration to necessary minimum (only environment creation) • Common gLite control panel that controls individual services (long term future) Configuration

6. Storing configuration • Key aspects • use unique format for configuration • Human readability • enforce structure (key value pair is not enough) • Enable local/centralized configuration • File system • DB • web • … • Enforce configuration verification (e.g. via schema) • Guide user in what needs to be changed • Group configuration values according to • User parameters that need to be changed (e.g. hostname) • Optimization parameters that might be changed • System parameters that should not be changed • Support user in choosing the correct configuration • documentation • sample values • default values • units • Allow common configuration for whole site Configuration

7. Storing configuration • Present status • xml configuration file format • somehow human readable • Structure enforceable • common set of configuration files in $GLITE_LOCATION/etc/config/ • one global configuration file • one configuration file per service (e.g. Workload Management Service) • for some services common service configuration file (e.g. RGMA common configuration file) • templates provided with default values and “changeme” • configuration files support • documentation • arrays • multiple instances • site configuration file • Contains parameters that are common for a site • Stored on webserver • order is user (highest) / common / site (lowest) configuration file Configuration

8. Example configuration file <!-- Default configuration parameters for the gLite RGMA server --> <config> <parameters> <!-- User-defined parameters - Please change them --> <rgma.server.mysql_root_password description="MySQL root password.” value="changeme"/> <rgma.server.run_schema_service description="Run a schema service for the rgma server on your machine (yes|no). If you want to run it on your machine set 'yes' and set 'rgma.schema.hostname' to the hostname of your machine otherwise set 'no' and set 'rgma.schema.hostname' to the hostname of the schema server you want to use. “ value="changeme"/> <!-- Advanced parameters - Change them if you know what you're doing --> <rgma.server.httpconnector_maxthread description="Maximum number of threads that are created for the tomcat http connector to process requests. This, in turn specifies the maximum number of concurrent requests that the Connector can handle. “ value="1000"/> <!-- System parameters - You should leave these alone --> Configuration

9. Storing configuration • Next (possible) steps: • cleanup of variable naming • Improvement of xml structure • Proper documentation • Sample values … • Schema • verification of configuration files and values via schema • graphical configuration tool • work in progress: • How to store “secret parameters” – e.g. passwords • How to treat values that should be put back to default values • Saving of old configurations • ….. Configuration

10. Accessing configuration • Key aspects • Two generic access points • Human/Management side • Application side • Provide easy access of the configuration values by providing APIs • Manager/Human • Manager should have one common place (management console) to look and change the configuration • Manager of system does notneed to know what needs to be reconfigured/restarted after a change of configuration • Application • one common interface • language and platform depending implementations • All services should have the same implementation for a given language/platform • Common approach to access configuration values from applications Configuration

11. Accessing configuration • Present status • Copying of configuration • deployment scripts copy configuration to service specific configuration files • Services read their specific configuration files • Scattered configuration files • Individual formats • Steps toward a common solution • Proposal for common configuration/control approach • Web services: JMX (see next slides) • C++: gLite Configurator (see next slides) Configuration

12. Web services requirements • Requirements for “production quality” web services • Control of the web service • Configuration • change web service dynamically • Lifecycle-specific requirements • start & stop • check if service is alive (pinging) • Produce load statistics • Request of service information • to describe how many messages it is processing at a given time • to display its identification, its current version number • to display its current set of dependencies • Manage the performance of web services (goes together with testing) • response time • uptime • management tool should take the quality of service as input • Metering the usage of web services: log number of messages from different users • Debugging of services • Make internals visible for debugging, finding of bottlenecks • request that the service sends any error message to a named target or file • SOAP message monitoring: see incoming/outgoing messages • SOAP message logging Configuration

13. Web services - JMX • Use available container techniques where applicable • Extend techniques where needed to provide common approach for the management • Common set of web service interfaces • Common configuration • Allow dynamic configuration • A possible solution: JMX – Java Management extensions • Standard designed for enabling resource management of/with Java applications • Extension of Java following standard specification • Specification within the Java Community Process (JCP) as a Java Submission Request (JSR3, JSR77, JSR xx Remote) • Several active implementations – commercial and open source • Each implementation follows the standard and gives some extras • Integrated in SUN Java 1.5 • Accepted standard in industry - used in several commercial products • Enables you to do dynamic configuration • Enables you to retrieve configuration information remotely • Enables you to read configuration from different places • …. much more like monitoring etc. … Configuration

14. Management application Client connector Java VM Adapter Adapter Server Connector Agent Service Agent Service Managed resource Managed resource MBean MBean MBean Web services - JMX Distributed ServiceLayer AgentLayer MBean Server InstrumentationLayer Configuration

15. Web services - JMX Tomcat Container Service specificWSDL Service service logic Service MBean gLite Manager gLiteService Configuration MBean connector commonWSDL MBeanServer commonWSDL Service adaptor gLiteService Configuration MBean Management Application Tomcat manager service logic Configuration

16. C++ services • C++: gLiteConfigurator • Configuration based on the Service Configurator approach • Service Configurator is designed as an internal part of the service • Role of the Service Configurator : • Hide OS dependent issues from the service (messaging, …) • Create an unique interface for the management of the services • Load service configuration and forward it to the service logic • Enable addition of the additional common functionality (instru-mentation) to the services, by providing an unique interface to it Configuration

17. C++ services Service Configurator Service logic OS OS dependent signals Unique, OS independent interface Linux signals MS Windows messages start stop init reconfigure info status start stop init reconfigure info status Reading configuration parameters Service Configuration

18. Accessing configuration • Next (possible) steps: • Discussion in Padova was very controversial • “JMX extra burden …” • “We don’t need central files …” • “We don’t need dynamic reconfiguration …” • A lot of developers don’t want to spend the effort (now) • First implementations • Data Management for C++ • Computing element for JMX Configuration

19. Changing configuration • Key aspects • Controlled change of configuration • Manager changes configuration via a common management console • Changing the configuration should automatically trigger the necessary actions • Reconfigure applications dynamically for dynamic configuration values (e.g. logging, debug levels) • Restart applications for static configuration values (e.g. port number) • Take into account the dependencies between applications • e.g. to restart tomcat the web services have to be restarted as well • Take into account the state of the application • an application wants to finish a transaction first • Track changes • What is the actual configuration of the application? • What is the last good configuration?  Monitoring Configuration

20. The global picture • We foresee a modular structure • ServiceConfigurator • sits inside the service and is the unique interface to • access configuration • get configuration values (e.g. for monitoring) • give common functionalities (e.g. start/stop) if they are not implemented by the container • reuse container capabilities • gLiteConfigurator • global tool to • manipulate configuration (management console) • start/stop services • provide WBEM interface … • ... First step is getting the ServiceConfigurator going … Configuration

21. Discussion time … Configuration

22. Extra slide: Services using container Management Console GliteConfigurator Container read Service Configurator Service Manager Service Configurator read write read Service logic Service logic command Service description file Container logic Configuration file Configuration