The current configuration scheme for AstroGrid uses a single properties file stored in Tomcat's $CATALINA_HOME/conf directory. This works -- we can deploy and run services -- but we may be able to make it work better and in more situations. This paper suggests an evolution of the scheme.

This may be out of date now but I've been combining in new Config stuff so this makes a good place to discuss it - MCH

What are we trying to do?

A list of requirements and constraints and stuff:

  • Make it easy for sysadmins to configure our stuff
  • Updates should not require re-entering configuration
  • Configuration changes for one component should not interfere with anothers
  • Components should come with a default configuration that allows the component to work and self-test straight out of the box. But a default configuration should not overwrite existing ones for upgrades...
  • Configuration must cope with multiple instances of one component on a single server.
  • Failures to find configuration files or values must be clearly indicated and easy to trace.
  • It must be easy to trace where the configuration has been loaded from even when there are no errors.

Move the config file to a web-app

We could move AstroGridConfig.properties to a web application just for configuration and management of AstroGrid components. Call it the /astrogrid context for sake of argument. It would be installed once, as an AstroGrid component in its own right, instead of being installed as a part of the installation of other components.

Pro:

  • Simplifies installation of other components.
  • Removes risk of components overwriting each other's configuration.
  • Location is independent of Tomcat conventions; may work better in WebSphere etc.

Con:

  • Requires a web service to run a component - awkward for testing & debugging.
  • Degraded performance - may not be significant
  • Extra effort to set up and maintain web interface

Install the default configuration using a WAR

We should build the astrogrid web-app using Maven and package it as a WAR, just like we do with the other components.

Pro:

  • Uses same installation scheme.
  • Default configuration can be done with a browser using Tomcat's manager interface.
  • We always have a default configuration.

Con: can't think of anything significant.

Put the config files in the web-readable part of the web-app

We could put the files either in the WEB-INF part of the web-app, which hides them from web browsers, or in the part that is served to browsers. I think making them accessible through the web would be better.

Pro:

  • We can access the configuration via HTTP URLs, e.g. http://localhost:8080/astrogrid/AstroGridConfig.properties.
  • We can check the configuration of remote sites via the web; this would be useful when the software is deployed at data-centres.

Con:

  • Secrets, such as JDBC passwords, can't be public.
  • Can't quite predict the absolute URL at build time; port number is variable.

Alternatively, we can keep it private so that we don't have security problems, but provide a 'dumpConfig' method that can return safe key/values, and include on the self-test pages. This also means that you see what the configuration really has in it, not the contents of a file that you think is being loaded into it - MCH

Allow alternative configurations for different web-apps.

AstroGrid components are now being deployed into separate web-apps in separate contexts. If we need components to have different configurations -- e.g. datacenter installations for different databases -- then these should have separate properties files.

Pro:

  • Can have more than one copy of a component.
  • Can have more than one version of a component.
  • Properties files are still central and acccessible.

Con:

  • Not obvious which context is using which configuration.

We need to allow for multiple datasets (in different databases) on one installation. Similarly there may be several 'applications' (eg HyperZ , SExtractor) installed on the same server - in fact it might be that there several HyperZ 's, set up with different standard configurations. I am planning on adding a 'context' to the keys for the datacenters, so that sysadmins still have one central file to edit but the different contexts are clear. - MCH

Name the properties files for the contexts to which they apply

AstroGridConfig.properties is redundant as a name when the file is in astrogrid. We could rename that file default.properties because it applies to the default context. We might then have, say, warehouse.properties for another context.

Pro:

  • Makes it obvious how the contexts apply.
  • Changes to a file are unlikely to impact other components
  • Installing new components with default configurations is easy and does not impact the existing configs

Con:

  • Means the sysadmin has to hunt around to find the right config file for the right component.
  • Multiple components result in several, eg, datacenter.properties files.

Refactor the properties files

Properties can be divided into those that are set by the authors of components -- e.g. warehouse defines the querier plug-in to be a WarehouseQuerier -- and those that should be set by the person doing the installation -- e.g. the default MySpace server. Where possible, we could put the latter type in separate configurations inside the web-apps they apply to.

Pro:

  • Central configuration is smaller, easier to handle.
  • No risk of external users changing properties they shouldn't vary.

Con:

  • Harder to change "private" parameters for special cases.
  • Are there parameters that are "private" but apply to more than one web-app?
  • There are parameters that are private in one context but not another - eg the DatacenterQuerier smile

Use JNDI to find the properties files

Components won't necessarily know which property file to read. In the datacenter component, the location -- actually the absolute file-path in the local file-system -- of the property file is set using the JNDI interface built into Tomcat. The datacenter web-app then calls JNDI (using the API built into J2SE ) to get the location. We could extend this to all AstroGrid components and set different locations for components that don't want to use the default configuration.

Pro:

  • Uniform way of locating configurations.
  • JNDI API always available to web-app.
  • Can make these settings in Tomcat via web browser.

Con:

  • Not clear that all web containers provide JNDI.
  • JNDI not always available in other environments - eg testing
  • Tomcat interface for this is a bit cryptic.
  • Setting the location is not easily scriptable.

-- GuyRixon - 18 Dec 2003

Use JNDI to hold the configuration

Which is what it's for.

Pro:

  • Standard way of configuring your web application
  • JNDI API always available to web-app.
  • Can make these settings in Tomcat via web browser.

Con:

  • Not clear that all web containers provide JNDI.
  • JNDI not always available in other environments - eg testing
  • Tomcat interface for this is a bit cryptic.
  • I think... that if you redeploy a WAR, you lose all your JNDI configuration.
  • Limited length of string fields?

-- MartinHill 04 Mar 2004

Topic revision: r2 - 2004-03-04 - 20:04:00 - MartinHill
 
AstroGrid Service Click here for the
AstroGrid Service Web
This is the AstroGrid
Development Wiki

This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback