This wiki is obsolete, see the NorduGrid web pages for up to date information.

HED Configuration Classes

From NorduGrid
Jump to navigationJump to search

HED Configuration Classes


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.


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.


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.