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

2. Content Idea of this presentation General aspects
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 all the 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. “
<!-- 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 not need 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 Common set of web service interfaces
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. Distributed Service Layer Instrumentation Layer
Web services - JMX
Management
application
Distributed Service Layer
Adapter
Server
Connector
Client
connector
Java VM
Agent Layer
Agent
Service
MBean Server
Managed resource
Instrumentation Layer
MBean
Configuration

15. Management Application
Web services - JMX
Tomcat Container
Service specific WSDL
Service
service
logic
Service
MBean
gLite Manager
gLite Service
Configuration
MBean
connector
common WSDL
MBean Server
common WSDL
Service
adaptor
gLite Service
Configuration
MBean
Management Application
service
logic
Tomcat
manager
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. Reading configuration parameters
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. First step is getting the ServiceConfigurator going …
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