Generalization of VO and Setup specific configuration settings

This RFC aims to harmonize a single approach to the description of VO/setup -specific configurations for the main configuration sections.

Consider the existing concept

We have next DIRAC configuration structure now, which was formed historically based on ease of use and other developer motivations:

DIRAC/..
Registry/..
Systems/..
WebApp/..
Resources/..
Operations/..

The Operations section was originally created to define operational options for pilots, and so on. But with the advent of multi-VO installations, an Operations section structure was organised to allow definition options for each VO and setup.

Consider how Operations works now

Operations section has the following structure:

Operations/
  Defaults/
    path_to_option/my_option=my_value_def
  my_setup/
    path_to_option/my_option=my_value_setup
  my_vo/Defaults/
         path_to_option/my_option=my_value_vo_def
  my_vo/my_setup/
         path_to_option/my_option=my_value_vo_setup

• Defaults -- section where default settings for all VO and setups are defined
• my_setup -- section with setup name where "my_setup" setup-special settings are defined
• my_vo/Defaults -- section where default settings for "my_vo" are defined
• my_vo/my_setup -- section where settings for "my_vo" in the "my_setup" context are defined

Path to my_option should be the same(in the case of the same option) for all the sections described above, the section in which it will be absent will not be taken into account in the calculation of my_option.

Thus in this section began to appear options from other sections for mapping them to VO. In fact, the Operations section has historically become the preferred place to describe the VO/setup-specific configuration.

Let's take a more specific example

For example we can find in the Operations section options that defaults value is defined in Resources section also.

Resources/
  FileCatalogs/<catalog name>/
                AccessType = Read-Write
                ...
Operations/
  <vo>/<setup>/
        Services/Catalogs/<catalog name>/
                           AccessType = Read
                           ...

Thus, we have the following ways for accessing this settings:

# access a default configuration which does not consider VO and a setup. The following examples CAN have the DIFFERENT result.
gConfig.getValue('/Resources/FileCatalogs/<catalog name>/AccessType')
gConfig.getValue('/Operations/Defaults/Services/Catalogs/<catalog name>/AccessType')

# receives a configuration considering VO and a setup. The Resources section is NOT taken into account.
Operations(<vo>, <setup>).getValue('/Services/Catalogs/<catalog name>/AccessType')

Can it be more clearly?

As we can see from the example of these queries, only last section name in a path and option name are common here. The query can look much more consistent where full path will be one:

# access a default configuration which does not consider VO and a setup
gConfig.getValue('/Resources/FileCatalogs/<catalog name>/AccessType')

# receives a configuration considering VO and a setup. The following examples will have the same result.
Operations(<vo>, <setup>).getValue('/Resources/FileCatalogs/<catalog name>/AccessType')
Operations(<vo>, <setup>, 'Resources').getValue('FileCatalogs/<catalog name>/AccessType')
Operations(<vo>, <setup>, 'Resources/FileCatalogs').getValue('<catalog name>/AccessType')

But how much change does it need?

1. Section path in Operations structure must be the same as in original root section:

Resources/
  FileCatalogs/<catalog name>/
                AccessType = Read-Write
                ...
Operations/
  <vo>/<setup>/
      Resources/FileCatalogs/<catalog name>/
                              AccessType = Read
                              ...

2. Forgot about /Operations/Defaults for non-Operations root sections.

3. A couple of lines in Operations helper class.

Resources is not the only one root section that contains options that may differ for different VO/setups. Thus the Operations section becomes a standart place of navigation on VO/setup for any root section.

The concept itself

The idea is to form a single concept of recording settings that depend on VO and setups with minimal changes, using the advantages of the historically formed configuration structure.

1. the root remains unchanged, the sections in the root contain general(default) configurations specific to the area that reflects the name of the section.

DIRAC/..
Registry/..
Systems/..
WebApp/..
Resources/..
Operations/..

2. Operations remains a specific section with the principle of operation described above, but with one difference: The Operations/Defaults subsection will only be used to write default options specific to the Operations section itself, and default options specific to other root sections must be in them.

Resources/
  resources_option = res_default_value
Operations/
  Defaults/
    operations_option = ops_default_value
  <vo>/<setup>/
      operations_option = ops_vo_setup_value
      Resources/
        resources_option = res_vo_setup_value

The advantages are..

• the whole configuration is sensitive to VO/setups are concentrated in one section (in Operations, as it was before).
• The overall root structure remains as it was.
• The option path for gConfig and for Operations() queries is similar.
• not much change is needed.

OK, how about backward compatibility?

It is clear that the adoption of some general concept of configuration implementation should take into account the transition period and gradual integration. Therefore, interference with the code must take into account backward compatibility. The main change in the code is a pair of lines in the Operations helper class, which adds a new mainSection argument and the corresponding behavior when searching for options described above. This change does not affect the result of using the Operations class without this new argument, which means that the code remains completely backward compatible.

How about WebApp?

WebApp contains a configuration about the web portal and is not structurally different from other sections. The WebApp section also needs the ability to define options regarding VO and setup. Therefore, there is nothing specific from the above.