HED Configuration Classes

HED Configuration Classes

Description

Currently HED provides configuration class UserConfig which takes care of:

• Finding and reading coonfiguration file of user
• Finding X.509 credentials of user
• Sorting out parameters specific to handling Grid jobs.

Currently this class is mostly used by job management code (libarcclinet + SHCs) and data management code (libarcdata2 + DMCs).

As one can see this class is mostly oriented towards managing Grid jobs. Internally it also heavily uses environment variables and current accounts attributes (like home directory). That also makes it mostly usable in client tools.

Issues

Various usage circumstances

Those features of UserConfig make it difficult to use under circumstances when properties of the user are not tightly related to local account. For example when server need to connect another server on behalf of some Grid user.

Possible solution could be to use multiple configuration classes tuned for different purposes.

Unneeded configuration parameters

Another problem is caused by too many configuration parameters which UserConfig is trying to define in its constructors. Some (many) of them may be not needed and still can cause configuration failure. Sometimes it is difficult to predict which parameters may be needed later and hence choosing right constructor becomes problematic. For example it is difficult to predict if data transfer will require X.509 credentials.

One of the posible solutions could be to make detection and verification of (some) cconfiguration parameters to happen on first request instead of doing that in constructor.

Current situation

Main configuration class is UserConfig.

Proposed new hierarchy

class Config (base class)

This class is passed to all methods which expect configuration parameters.

Internally it is then casted into following classes if needed (but not further than one step)

class X509Config inherits from Config

stores and provides X509 credentials

accepts credentials as blobs and from files (should they be read once and stored in memory?)

class X509UserConfig inherits from X509Config

gueses locations of credentials using account attributes and environement variables

checks permissions on files

asks for passwords for encrypted credentials

performs additional validity checks if needed (like if proper chain is present)

class JobConfig inherits from Config

stores configuration parameters needed for job submission

class JobUserConfig inherits from JobConfig

finds location of job realted configuration, job list, etc using account attributes and environment variables

performs any account related checks needed

class DataConfig inherits from Config

stores configuration parameters needed for data transfers (maybe Chelonia access point, SRM ports)

class DataUserConfig inherits from DataConfig

finds location of data related configuration, job list, etc using account attributes and environment variables

performs any account related checks needed

Combining objects into complex configuration

• Solution A

class UserConfig inherits DataUserConfig, JobUserConfig, X509UserConfig

Combines all configurations and instantiates it related to user account

May cause troubles with Java and Python. Those do not support multiple inheritance. But maybe multiply inherited class can simply be wrapped. Or maybe multiple implementation of interfaces feature may be used.

• Solution B

class AllConfig

contains list of Config objects and provides methods for accessing them.

Assignments

During technical workshop hierarchy proposal was presented and accepted. It was desided that Aleksandr takes Config, X509Config, X509UserConfig. Then Mattias or Martin take Job*Confsig. David takes Data*Config. People responsible for rest of code are to switch to new configuration classes after those are ready.