-
Notifications
You must be signed in to change notification settings - Fork 176
DIRAC v7r2
For server installations: the runit scripts have to be modified to run dirac-service
instead of $DIRAC/DIRAC/Core/scripts/dirac-service.py
. Same for dirac-agent
and dirac-executor
. So, login in each of your server installations, sudo su dirac
and run:
sed -i.bak -E 's@python \$DIRAC/DIRAC/Core/scripts/dirac[-_]([a-z]+)\.py@dirac-\1@g' /opt/dirac/runit/*/*/run
HTTPS and WebApp services will also need to be changed from exec python /path/to/something.py
to exec something
.
This is optional in v7r2 but will be required before moving to v7r3.
With this version, there is a experimental support for Python 3 based, using DIRACOS2 and python pip
. The installation instructions can be found in DIRAC main README file.
If you have a DIRAC extension, and want to run python3 clients of your DIRAC extension, there are a few things to be done on your side:
- The structure with src/PROJECTNAME/code... should be adopted
- A
setup.py
and/orsetup.cfg
file(s) should be written. See examples in LHCbDIRAC devel code - For Vanilla projects this affects COMDIRAC, and VMDIRAC, while WebAppDIRAC is only server, so no need to update immediately.
ElasticSearch version 7.x is now supported. The support for version 5 or earlier could not be assured.
In order to support multi VO and make the InputData module work with certificate needs to be moved to Operations section (https://github.com/DIRACGrid/DIRAC/pull/4339):
/DIRAC/VOPolicy/InputDataModule -> /DIRAC/Operations/InputDataPolicy/InputDataModule
also since https://github.com/DIRACGrid/DIRAC/pull/5172:
/DIRAC/VOPolicy/SoftwareDistModule -> /DIRAC/Operations/SoftwareDistModule
yes, into the base section.
The home made wrapper of openssl (pyGSI
) has been finally fully removed in favor of the more standard M2Crypto
library.
It was first made available in v7r0 and was the default in v7r1.
M2Crypto (or any standard tool that respects TLS..) is stricter than PyGSI. So you may need to adapt your environment a bit. Here are a few hints:
- SAN in your certificates: if you are contacting a machine using its aliases, make sure that all the aliases are in the SubjectAlternativeName (SAN) field of the certificates
- FQDN in the configuration: SAN normally contains only FQDN, so make sure you use the FQDN in the CS as well (e.g.
mymachine.cern.ch
and notmymachine
) - ComponentInstaller screwed: like any change you do on your hosts, the ComponentInstaller will duplicate the entry. So if you change the CS to put FQDN, the machine will appear twice.
Within PR https://github.com/DIRACGrid/DIRAC/pull/4956 we renamed a few columns of MySQL tables, to avoid conflicts with reserved keywords in MySQL 8. Specifically:
InstalledComponentsDB.Component.System -> InstalledComponentsDB.Component.DIRACSystem
InstalledComponentsDB.Component.Module -> InstalledComponentsDB.Component.DIRACModule
ALTER TABLE `Components` RENAME COLUMN `System` TO `DIRACSystem`
ALTER TABLE `Components` RENAME COLUMN `Module` TO `DIRACModule`
For mysql version 13 the commands to update the database are:
ALTER TABLE Components CHANGE System DIRACSystem varchar(32) NOT NULL;
ALTER TABLE Components CHANGE Module DIRACModule varchar(32) NOT NULL;
Additionally, #5092 lengthens the DIRACVersion
column to account for the potentially longer version numbers in Python 3 based installations:
USE InstalledComponentsDB;
ALTER TABLE HostLogging MODIFY COLUMN DIRACVersion varchar(64);
Within https://github.com/DIRACGrid/DIRAC/pull/4610 we changed the way the logger level is set to make it closer to the standard logging
library. The level is currently managed in a strange way:
- the logger level is always debug
-
Logging.setLevel()
just change the level of the Backends (so of the handlers) attached to the Logging
This was done in order to make sure that the centralized logging could not be disabled: all logs from all Logging objects go to a MessageQueue for instance.
In practice, subloggers don't have any Backend and just propagate the logs to LoggingRoot
that spreads the logs across its Backends.
Thus, Logging.setLevel()
has no effect from a sublogger.
From v7r2 the Logging level is attached to the logger level to better respect the standard mechanism:
-
Logging.setLevel()
works from every sublogger and change the level of its underlying logger - Backend level can still be changed from the configuration to only allow log records from a certain level
This means that the centralized logging can only get logs that respects the following condition: log record level > logger level:
- the lower the
Logging
level, the more logs you will get in the centralized logging system - to only get logs from a certain level in a specific Backend (e.g.
INFO
in stdout), make sure to set its LogLevel in the configuration (see https://github.com/DIRACGrid/DIRAC/blob/rel-v7r2/docs/source/DeveloperGuide/AddingNewComponents/Utilities/gLogger/Backends/index.rst):
LogBackends
{
Stdout
{
LogLevel='INFO'
}
}
Keep in mind that if you change the Backend level, you will not be able to get logs below this level, even if you change the Logging
level.
There is a new agent with some functionality to supervise the state of services, agents, and executors: https://dirac.readthedocs.io/en/latest/CodeDocumentation/FrameworkSystem/Agent/ComponentSupervisionAgent.html
Note (July 26, 2021): This is not yet ready for use!
-
Component
monitoring type should now be reliable- NEW: RMSMonitoring
In order to enable RMSMonitoring
we need to set value of EnableActivityMonitoring
flag to yes/true inside
/Operations/Defaults
or /Systems/RequestManagement/<Instance>/Agents/RequestExecutingAgent
of the cfg file.
The PR 4874 did two things:
- removed the ConfigurationServer hook for updating the pilot files.
- introduced a new agent and a script for helping synchronizing the pilot files, offering a way to solve issue 4697. The agent is called
PilotSyncAgent
and can be installed as all other agents using thedirac-admin-sysadmin-cli
. Please refer to the agent documentation for a complete info on how to use it. - A script is also provided with the same functionalities of the agent.
From #4367
To activate, add CompressJDLs=True
option in /Systems/WorkloadManagement/<setup>/DB/JobDB
Following a previous "tech preview" annouce, you can now safely use ElasticSearch for Job Parameters: see doc
PR https://github.com/DIRACGrid/DIRAC/pull/4905 adds a new flag to the StatesAccountingAgent, called Backend
, which can take the value of Accounting
(which is the default), or Monitoring
or Accounting,Monitoring
. If Monitoring
is in the backends list, then the StatesAccountingAgent replaces the StatesMonitoringAgent by committing to (also) the ElasticSearch backend of the Monitoring system.
Run the following MySQL commands:
use ResourceManagementDB;
ALTER TABLE `DowntimeCache` MODIFY `DowntimeID` VARCHAR(127);
The file etc/web.cfg
is not read anymore: before upgrading/installing, make sure that its content is added top the CS.
Starting with this version, a description of the organization of the simple server file to serve the static files, this is not necessarily an additional option. For this, in addition to nginx itself, you need to install the web dev plug-in, what is described in the WebAppDIRAC
installation instructions. Note that this nginx configuration can also be installed separately from the web portal and used as an additional file server.
This is only if you use the LHCb managers (FileManagerPS
and DirectoryClosure
). Following #5057, 4 procedures need to be recreated:
ps_get_dir_logical_size
ps_calculate_dir_logical_size
ps_get_dir_physical_size
ps_calculate_dir_physical_size
To do so, basically connect to the DB and execute this whole block https://github.com/DIRACGrid/DIRAC/blob/4176025445ff0b79d5b3aecf862ecb47139e0756/src/DIRAC/DataManagementSystem/DB/FileCatalogWithFkAndPsDB.sql#L1647-L1801