Generalizing VO and Setup specific configuration

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 for ease of use:

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 define options for each VO and setup.

Thus in this section began to appear options from other sections for mapping them to VO. For example we can find in the Operations section options that defaults value is defined in Resources section also.

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

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

gConfig.getValue('/Resources/FileCatalogs/<file catalog name>/AccessType')
gConfig.getValue('/Operations/Defaults/Services/Catalogs/<file catalog name>/AccessType')

Operations(<vo name>, <setup name>).getValue('/Services/Catalogs/<file catalog name>/AccessType')

Can it be more clearly?

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

gConfig.getValue('/Resources/FileCatalogs/<file catalog name>/AccessType')

Operations(<vo name>, <setup name>).getValue('/Resources/FileCatalogs/<file catalog name>/AccessType')
Operations(<vo name>, <setup name>, 'Resources').getValue('FileCatalogs/<file catalog name>/AccessType')
Operations(<vo name>, <setup name>, 'Resources/FileCatalogs').getValue('<file 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/
    <file catalog name>/
      AccessType = Read-Write
      ...
Operations/
  <vo name>/
    <setup name>/
      Resources/
        FileCatalogs/
          <file catalog name>/
            AccessType = Read-Write
            ...

2. Forgot about /Operations/Defaults in 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 universal place of navigation on VO/setup for any root section.

OK, how about 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.

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.
• No need to make many changes.
• No need additional sections.

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.