Difference: GIP (1 vs. 2)

Revision 22008-01-21 - LaurenceField

Line: 1 to 1
 
META TOPICPARENT name="EGEEMiddlewareSupport"

Generic Information Provider

Added:
>
>

Overview

The Generic Information Provider, GIP, is a framework which simplifies the creation and deployment of information providers. The GIP enables smaller plugins to be used which makes it easier to support new systems by separating static and dynamic information. It can be used in conjunction with other LDAP based grid information system components to inject information into the system.
 
Changed:
<
<
The Generic Information Provider, GIP, is a highly configurable information provider that makes a separation between static and dynamic information. It can be used to produce any kind of information for use with LDAP based grid information systems.

An information provider in its simplest form is a script that prints an LDIF file to standard out. The LDIF file should conform to the schema used in the GIP. The problem is with dynamic information. It is for this reason that there currently exists many different information providers written by many different people and that require many different methods of configuration. Usually there are only a few attributes that have to be found dynamically. The idea with the GIP is to use dynamic plug-ins to obtain these values and use a common framework for everything else.

The GIP configuration file contains all the configuration parameters for the GIP.

temp_dir

The directory to use as the GIPs cache.

plugin_dir

The directory where to put links to the dynamic plugins.

static_dir

The directory where to put inks to the static ldif files.

provider_dir

The directory where to put links to the information providers.

freshness

How long to use the cache before running the dynamic plugins again.

cache_ttl

How long the cache is valid.

response

How long the GIP will wait for dynamic plugins before continuing.

timeout

Timeout for the dynamic plugins in seconds.

The GIP script reads in all the ldif files from the static_dir and run all the providers in the plugin_dir. It will then run any dynamic plug-ins found in the plugin_dir to obtain the dynamic values. It will print the LDIF to standard out but use the any dynamic values found from the plugins. Plugins and providers should not be put directly into the directory, insted a symbolic link or wrapper script should be used. This enables us to turn them on and off without having to remove the software.

The advantage of this framework is that it reduces the number of packages, lines of code, different configuration methods etc. To use new dynamics sources only a new dynamic plug-in is required.

>
>
An information provider in its simplest form is a script that prints an LDIF file to standard out. The LDIF file should conform to the schema used. There are usually only a few attributes that have to be found dynamically from a specific system. To avoid the creation of many different information providers that duplicate much of thier functionality, the GIP uses a plugin mechanism to obtain these dynamic values from the specific system.
 
Added:
>
>
The GIP reads in all the LDIF files from the static directory. Depending on the state of the cache, the information providers in the providers directory and dynamic plug-ins found in the_plugin_ directory are run and the output stored in a temporary directory before updating the cache. When the providers or plugins are executed, a lock file is placed in the lock directory to stop multiple instances being spawned. The dn is used to identify attributes and values from the same entry entry. The cached entries resulting from ruining information providers will overwrite entries from the static files. The cached values from the dynamic plug-ins will overwrite the values from static files and/or information providers. The resulting LDIF is then printed to standard out. Instead of putting plugins and providers directly into the directories, symbolic links or wrapper scripts can be used. This enables them to be turned on and off without having to uninstall them.
 
Added:
>
>

Configuration

The GIP has only one configuration file:
  • /opt/glite/etc/gip/glite-info-generic.conf

glite-info-generic.conf

This configuration file is used to configure the GIP itself. The format is key/value pairs with an '=' sign as the separator. A default configuration file comes with the GIP. This may require editing in order for the GIPto function as desired. The table belows describes the key/value pairs found in the configuration file.

Key Typical Value Description  
temp_dir /opt/glite/var/tmp/gip The temporary directory used by the GIP
cache_dir /opt/glite/var/cache/gip The directory containing the cache files
lock_dir /opt/glite/var/lock/gip The directory containing the lock files
static_dir /opt/glite/etc/gip/ldif The directory where to put the static LDIF files
provider_dir /opt/glite/etc/gip/provider The directory where to put information providers
plugin_dir /opt/glite/etc/gip/plugin The directory where to put the dynamic plugins
freshness 60 How long in seconds to use the cache before running the dynamic plugins again
cache_ttl 300 How long in seconds the cache is valid
response 5 How long in seconds the GIP will wait for dynamic plugins before continuing
timeout 30 Timeout in sceonds for the dynamic plugins
  -- LaurenceField - 31 Aug 2006 \ No newline at end of file

Revision 12006-08-31 - LaurenceField

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="EGEEMiddlewareSupport"

Generic Information Provider

The Generic Information Provider, GIP, is a highly configurable information provider that makes a separation between static and dynamic information. It can be used to produce any kind of information for use with LDAP based grid information systems.

An information provider in its simplest form is a script that prints an LDIF file to standard out. The LDIF file should conform to the schema used in the GIP. The problem is with dynamic information. It is for this reason that there currently exists many different information providers written by many different people and that require many different methods of configuration. Usually there are only a few attributes that have to be found dynamically. The idea with the GIP is to use dynamic plug-ins to obtain these values and use a common framework for everything else.

The GIP configuration file contains all the configuration parameters for the GIP.

temp_dir

The directory to use as the GIPs cache.

plugin_dir

The directory where to put links to the dynamic plugins.

static_dir

The directory where to put inks to the static ldif files.

provider_dir

The directory where to put links to the information providers.

freshness

How long to use the cache before running the dynamic plugins again.

cache_ttl

How long the cache is valid.

response

How long the GIP will wait for dynamic plugins before continuing.

timeout

Timeout for the dynamic plugins in seconds.

The GIP script reads in all the ldif files from the static_dir and run all the providers in the plugin_dir. It will then run any dynamic plug-ins found in the plugin_dir to obtain the dynamic values. It will print the LDIF to standard out but use the any dynamic values found from the plugins. Plugins and providers should not be put directly into the directory, insted a symbolic link or wrapper script should be used. This enables us to turn them on and off without having to remove the software.

The advantage of this framework is that it reduces the number of packages, lines of code, different configuration methods etc. To use new dynamics sources only a new dynamic plug-in is required.

-- LaurenceField - 31 Aug 2006

 
This site is powered by the TWiki collaboration platform Powered by Perl 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? Ask a support question or Send feedback