docs: removed more mentions of setup

Author: fstagni

dirac.cfg

@@ -1043,7 +1043,7 @@ Operations
     # RMSMonitoring = ...
   }
   # This is the default section of operations.
-  # Any value here can be overwriten in the setup specific section
+  # Any value here can be overwriten in the VO specific section
   Defaults
   {
     # Flag for globally disabling the use of the SecurityLogging service
@@ -1188,9 +1188,4 @@ Operations
       }
     }
   }
-  # Options in this section will only be used when running with the
-  # <MySetup> setup
-  <MySetup>
-  {
-  }
 }

docs/source/AdministratorGuide/HowTo/SystemAdministratorInterface.rst

@@ -40,7 +40,6 @@ The following command shows information about the host setup and currently used
 
     volhcb03.cern.ch >show info
 
-    Setup: LHCb-Certification
     DIRAC version: v5r12-pre9
     LHCb version v5r11p10
     LHCbWeb version v1r1
@@ -64,11 +63,11 @@ The status of the installed components can be obtained like::
 
     volhcb01.cern.ch> show status
 
-       System                      Name                         Type         Setup    Installed Runit    Uptime    PID
-    --------------------------------------------------------------------------------------------------------------------
-    ResourceStatus               ResourceStatus               service        SetUp    Installed Down    2532910        0
-    WorkloadManagement           SandboxStore                 service        SetUp    Installed Run        8390    20510
-    WorkloadManagement           JobMonitoring                service        SetUp    Installed Run        8390    20494
+       System                      Name                         Type         Installed Runit    Uptime    PID
+    -----------------------------------------------------------------------------------------------------------
+    ResourceStatus               ResourceStatus               service        Installed Down    2532910        0
+    WorkloadManagement           SandboxStore                 service        Installed Run        8390    20510
+    WorkloadManagement           JobMonitoring                service        Installed Run        8390    20494
     ...
 
 The output of the command shows for each component its system, name and type as well as the status information:
@@ -78,7 +77,7 @@ The output of the command shows for each component its system, name and type as
   Runit system
 
 
-Show setup command allows administrators to know which components, Services and Agents are setup up in the host::
+Show setup command allows administrators to know which components, Services and Agents are setup in the host::
 
     mardirac1.in2p3.fr >show setup
     {'Agents': {'Configuration': ['CE2CSAgent'],

docs/source/AdministratorGuide/Resources/catalog.rst

@@ -9,7 +9,7 @@ Catalogs represent the namespace in DIRAC. They are queried based on the LFN. Ev
 The definition of catalogs is shared between two sections:
 
 * `/Resources/FileCatalogs`: this describes the catalog, how to access it, and all its options
-* `/Operations/<vo/setup>/Services/Catalogs/`: this describes how we use the catalog.
+* `/Operations/<vo>/Services/Catalogs/`: this describes how we use the catalog.
 
 Resources
 ---------

docs/source/AdministratorGuide/Systems/DataManagement/fts3.rst

@@ -173,7 +173,7 @@ They named this strategy *MultiHop* |trade|. It consists of turning a transfer `
 
 DIRAC supports one intermediate hop (note: not that it would be very hard to implement any number, but having to implement that feature to transfer between two WLCG sites is already afflicting enough, so let's not overdo it). The choice of the intermediate SE is done in the FTS3Plugin, so feel free to customize it (see above).
 
-The configuration of multihop is done in the form of a ``[source][destination]`` matrix in ``Operations/<vo/setup>/DataManagement/MultiHopMatrixOfShame``. You can:
+The configuration of multihop is done in the form of a ``[source][destination]`` matrix in ``Operations/<vo/DataManagement/MultiHopMatrixOfShame``. You can:
 
    * Use specific SE Names
    * Use ``BaseSE`` names

docs/source/AdministratorGuide/Systems/MonitoringSystem/index.rst

@@ -56,8 +56,7 @@ For example::
 
 The following option can be set in `Systems/Monitoring/Databases/MonitoringDB`:
 
-   *IndexPrefix*:  Prefix used to prepend to indexes created in the ES instance. If this
-                   is not present in the CS, the indices are prefixed with the setup name.
+   *IndexPrefix*:  Prefix used to prepend to indexes created in the ES instance.
 
 For each monitoring types managed, the Period (how often a new index is created)
 can be defined with::

docs/source/AdministratorGuide/Systems/Transformation/index.rst

@@ -127,7 +127,7 @@ Configuration
 
 * **Operations**
 
-  * In the Operations/[VO]/[SETUP]/Transformations or Operations/Defaults/Transformations section, *Transformation Types* must be added
+  * In the Operations/[VO]/Transformations or Operations/Defaults/Transformations section, *Transformation Types* must be added
   * By default, the WorkflowTaskAgent will treat all the *DataProcessing* transformations and the RequestTaskAgent all the *DataManipulation* ones
   * An example of working configuration is give below::
 

docs/source/DeveloperGuide/AddingNewComponents/Utilities/CSHelpers/Operations/index.rst

@@ -2,32 +2,30 @@
 Helper for accessing /Operations
 ==================================
 
-*/Operations* section is *VO* and *setup* aware. That means that configuration for different *VO/setup* will have a different CS path:
+*/Operations* section is *VO* aware. That means that configuration for different *VO* will have a different CS path:
 
  * For multi-VO installations */Operations/<vo>* should be used.
  * For single-VO installations */Operations* should be used.
 
-In any case, there is the possibility to define a default configuration, that is valid for all the *setups*. The *Defaults* keyword can be used instead of the setup. For instance */Operations/myvo/Defaults*.
+In any case, there is the possibility to define a default configuration, for instance */Operations/myvo/Defaults*.
+Take a look at :ref:`dirac-operations-cs` for further info.
 
-Parameters defined for a specific setup take precedence over parameters defined for the *Defaults* setup. Take a look at :ref:`dirac-operations-cs` for further info.
-
-To ease accessing the */Operations* section a helper has been created. This helper receives the *VO* and the *Setup* at instantiation and
-will calculate the *Operations* path automatically. Once instanced it's used as the *gConfig* object. An example would be:
+To ease accessing the */Operations* section a helper has been created. This helper receives the *VO* and will calculate the *Operations* path automatically. Once instanced it's used as the *gConfig* object. An example would be:
 
 .. code-block:: python
 
    from DIRAC.ConfigurationSystem.Client.Helpers.Operations import Operations
 
-   ops = Operations(vo="dirac", setup="Production")
+   ops = Operations(vo="myVO")
    #This would check the following paths and return the first one that is defined
-   # 1.- /Operations/dirac/Production/JobScheduling/CheckJobLimits
-   # 2.- /Operations/dirac/Defaults/JobScheduling/CheckJobLimits
+   # 1.- /Operations/myVO/JobScheduling/CheckJobLimits
+   # 2.- /Operations/Defaults/JobScheduling/CheckJobLimits
    # 3.- Return True
 
    print(ops.getValue("JobScheduling/CheckJobLimits", True))
 
 
-It's not necessary to define the *VO* if a group is known. The helper can extract the *VO* from the group.  It's also possible to skip the setup parameter and let it discover itself.  For instance:
+It's not necessary to define the *VO* if a group is known. The helper can extract the *VO* from the group.  For instance:
 
 .. code-block:: python
 

docs/source/DeveloperGuide/DevelopmentEnvironment/DeveloperInstallation/interactingWithProductionSetups.rst

@@ -15,7 +15,7 @@ So, the only real thing that you need to have is:
 
 The last 2 bullets can be achieved with the following command::
 
-   dirac-configure -S MyProductionSetup -C dips://some.whe.re:9135/Configuration/Server --SkipCAChecks
+   dirac-configure -C dips://some.whe.re:9135/Configuration/Server --SkipCAChecks
 
 Or simply by manual editing the dirac.cfg file.
 

docs/source/UserGuide/WebAppUserGuide/index.rst

@@ -39,7 +39,6 @@ Format of the URL:
 
 #. https://: protocol
 #. lhcb-portal-dirac.cern.ch/DIRAC/: host.
-#. s:LHCb-Production: DIRAC setup.
 #. g:lhcb_prmgr : role
 #. theme=Grey: it is the look and feel.
 #. &url_state=1: it is desktop or application.
@@ -309,37 +308,7 @@ You have to click on the **Settings** widget:
 You can define the following:
 
 * Group you can change the role
-* Setup: you can switch between different setups.
 * Theme you can change the look and feel and also you can switch between Tab and Desktop themes.
 
-We have 3 look and feels:
-
-#. Grey it is the default
-#. Neptune
-#. Classic
-
 You can automatically change the applications using *Automatic tab change* Note: After you set it you have to save the desktop.
 Consequently, you can not have automatic tab change in the *Default* desktop.
-
-**Grey**
-
-.. image:: images/grey.png
-   :scale: 30 %
-   :alt: Grey look and feel.
-   :align: center
-
-
-**Neptune**
-
-.. image:: images/neptune.png
-   :scale: 30 %
-   :alt: Neptune look and feel.
-   :align: center
-
-
-**Classic**
-
-.. image:: images/classic.png
-   :scale: 30 %
-   :alt: Classic look and feel.
-   :align: center

docs/source/UserGuide/WebPortalReference/Overview/index.rst

@@ -8,7 +8,7 @@ DIRAC Web Portal is a Web application which provides access to all the aspects o
 Description
 ========================
 
-All pages have two toolbars, one on the top and another at the bottom of the pages that contain the main navigation widgets. The top toolbar contains the main menu and reflects the logical structure of the Portal. It also allows to select active DIRAC setup. The bottom toolbar allows users to select their active group and displays the identity the user is connected with.
+All pages have two toolbars, one on the top and another at the bottom of the pages that contain the main navigation widgets. The top toolbar contains the main menu and reflects the logical structure of the Portal. The bottom toolbar allows users to select their active group and displays the identity the user is connected with.
 
 The mostly used layout within our Web Portal is a table on the right side of the page and a side bar on the left. Almost all data that needs to be displayed can be represented as two-dimensional matrix using a table widget. This widget has a built-in pagination mechanism and is very customizable. As a drawback, it is a bit slow to load the data into the table. On an average desktop hardware, tables with more than 100 elements can be slow to display the data.
 
@@ -22,7 +22,6 @@ The mostly used layout within our Web Portal is a table on the right side of the
 2. **Selections**: Shows a set of selectors than permits generate customs selections.
 3. **Buttons to open/collapse panels**: Permit open or collapse left menu.
 4. **Actions to perform for job(s)**: These actions permits select all, select none, reset, kill or submit
-5. **Menu to change DIRAC setup**: Users can change between different setups.
 6. **Current location**: Indicates where the user is located inside the portal.
 7. **Buttons to submit or reset the form**: After options are selected its possible to submit and execute the selection or reset the selectors.
 8. **Pagination controls**: Permits navigate between the pages, and also show in which page the user is navigating.