Release and Run FESA Software
To provide the FESA software for testing purposes in the development or integration environment or for production the software has to be released, e.g. for a FEC
For each FEC
to release FESA software to a FEC
folder has to be added withing the deploy-unit project (
). Be sure to use the hostname of the FEC/SCU only.
Do not add the appendix '.acc.gsi.de' to the name of the FEC
. An instance file will be created automatically. Additional instance files per FEC
can be created using the 'Add Instance' button (
) on the deploy-unit toolbar. During release the default instance file is considered.
: Your Linux user account needs to be in the group "fesa" to be able to release the FESA software. Please refer to CSCOIN if your account is not already in the fesa group.
(Virtual) Frontends ( vmla1x / scuxl0001... )
Release into different Environments
since FESA Eclipse Plug-In since version 2.9.8
: the state element in the FESA class/deploy-unit designs is not considered anymore. In a future FESA FWK version the state attribute will vanish.
The release environment can be selected in the FESA Eclipse Plug-In since version 2.9.8
. The release environment can be selected either globally for the whole workspace or during release of FESA3 software. Four different options are available for FESA3 developers:
|| CMW Directory Server
|| Development system to test early stages of FESA3 software
|| development cluster asl7x, SCU in development system or virtual FEC vmla01x
|| Integration system for testing new control system features
|| light steel blue
|| SCU in integration system or virtual FEC vmla01x
| In Use
|| FESA3-specific: Allows to release FESA3 software into the production environment without all of the workflow restrictions
|| red to indicate something fishy
|| SCU in production
|| GSI orange
|| SCU in production
Release environment mainly refers to the database and the CMW directory server used. During release of the FESA3 software in the FESA Eclipse Plug-In the appropriate settings are performed per FEC
(e.g. NFS initialisation start script selection in /common/export/nfsinit/<FECName>).
A development release has less restrictions than the release of operational software. Checks such as version control, code synchronization, code compilation or database exports may be skipped on demand (see FESA Preferences/Expert).
- Click on the appropriate 'Release' button (FESA class: / FESA deploy-unit: ) or right-click on the FESA project and select FESA > Release from the context menu
- Select the FEC(s) to release to from the list
According to the settings in the preferences the software will be synchronized, compiled, linked, exported to the database and copied to the release location (deploy-unit: /common/export/fesa/local/<FEC>/<FESA DU>(-d)) .
Renew the kerberos ticket prior to a productive release
If a productive release of a FESA deploy-unit is performed the following checks apply:
- The FESA software must be under version control and must be synchronized with the SVN repository.
- The FESA design will be automatically synchronized (source code generation).
- The FESA software will be compiled.
- The FESA design will be exported to the database (probably version increment required).
The settings in the FESA expert preferences will not
If available FESA class documentation will be uploaded to the webserver.
is adapted to use the CMW nameserver of the productive environment. Precisely this means that the symbolic links to the FESA start script are set differently:
50_fesa_dev -> ../global/fesa_64bit_dev_environment # CMW nameserver of development environment is used
50_fesa_int -> ../global/fesa_64bit_int_environment # CMW nameserver of integration system environment is used
50_fesa ->../global/fesa_64bit_pro_environment # CMW nameserver of production environment is used
If any of the restrictions cannot be fulfilled the release procedure fails.
The FESA deploy-unit is launched using the CMW nameserver within the production environment. This is achieved by launching the daemon which starts the FESA deploy-unit automatically with the parameter
This parameter is used in the FESA environment launch script for the integration system, e.g. /common/export/nfsinit/global/fesa_64bit_pro_environment .
A release into the integration system triggers the adjustment of the NFS initialisation scripts to use the integration system environment.
The FESA deploy-unit is launched using the CMW nameserver within the integration system environment. This is achieved by launching the daemon which starts the FESA deploy-unit automatically with the parameter
This parameter is used in the FESA environment launch script for the integration system, e.g. /common/export/nfsinit/global/fesa_64bit_int_environment .
If an operational release of a FESA deploy-unit the settings in the expert preferences are considered. No checks are forced. A FESA deploy-unit can be automatically delivered to its destination relatively freely.
The FESA deploy-unit is launched using the CMW nameserver within the development environment. This is achieved by launching the daemon which starts the FESA deploy-unit automatically with the parameter
This parameter is used in the FESA environment launch script for the development environment, e.g. /common/export/nfsinit/global/fesa_64bit_dev_environment .
"InUse" is used to indicate a state in which a FESA class/deploy-unit already was running in production at least once. If the state inUse is selected the release procedure is similar to the release of development software. The settings in the expert preferences apply. But the productive environment will be set in the end.
<a name='differentnameservers'></a>The main difference are the settings for the CMW nameserver to be used for running FESA software on a FEC
. A FESA deploy-unit that is marked as "inUse" in its design is supposed to use the CMW nameserver of the productive environment at run-time. This is achieved by launching the daemon which starts the FESA deploy-unit automatically with the parameter
This parameter is used in the FESA environment launch script /common/export/nfsinit/global/fesa_64bit_dev_environment .
Outside View - How to recognize a FESA deploy-unit which is "inUse":
A FESA deploy-unit marked as "inUse" running in the productive environment is recognizable by the classVersion returned by the Version Property. The string contains in this case not only the class version but also the information about the state the software is in.
How to locate the FESA Software in the different environments
See Getting Information from the FESA Database
- If a development release was performed change the folder name in /common/export/fesa/local/<FEC>/<FESA DU>-d to /common/export/fesa/local/<FEC>/<FESA DU> or provide a soft-link with the same name as the FESA deploy-unit
- SSH to the FEC (for the password please refer to ACO/IN)
[root@scuxl0123 ~]# reboot now
- login again and check which binaries are running
[root@scuxl0123 ~]#ps -a
- SSH to the FEC, e.g. ssh root@scuxl0123 # Please refer to the FESA team or ACO/IN for the password.
- cd to the folder of the deploy-unit, e.g. cd /opt/fesa/nfs/local/vmla01/<FESA DU>
- launch the start script manually
Development / Integration System Environment
Aims for asl740..asl744, virtual FECs
, dedicated SCUs.
To run FESA software on the development systems a release may not be necessary. The FESA software may run locally for testing purposes in the FEC
The access rights on the asl-cluster are restricted. Therefore FESA software can not be run with root rights. This means that the Linux RT priorities can not be used. As an alternative Linux' NICE scheduling is used. To trigger this behaviour use the command line argument -noRTSched when launching the FESA software with the start script. Please keep in mind that the RT priorities given in the deploy-unit- / instance-file will be converted to NICE-levels [0...99] --> [20 ... -19]. The maximum RT-priority that can be used on the asl-cluster is '50'. This value will be converted to a NICE priority level of '0'.
In order to e.g. run the binary of 'MyDeployUnit', follow these steps:
// Go to the folder where the manual start script is located e.g:
# cd myWorkspaceLocation/MyDeployUnit/src/test/asl7xx
// Launch the script:
# ./startManually_MyDeployUnit_X.sh -f -noRTSched -vv
// (-vv = very verbose ) Use the option -h to see a full list of possible arguments
// Stop the running FESA software by pressing CTRL + C
Aims for productive SCUs.
The procedure for the productive asl cluster is identical to the release procedure for FEC's.
Similar to the development cluster root rights are restricted.
For access via JAPC device information must be provided for the directory server (nameserver). This device information is stored in the FESA database.
Which information is stored in the TODO database can be retrieved using the tools described in
Please note that these tools are not yet adapted for distunguishing between the productive and the development database.
To verify the access to a device's properties a test tool is available: cscosv-device-test
. Besides debug output at the end the success/failure state of the involved access elements is summarized.
The tool requires two parameters: the name of the device-instance to be tested and the property to be called.
/common/usr/cscosv/opt/device-connectivity-test/bin/device-connectivity-test.sh <device name> <property>
/common/usr/fesa/bin/device-connectivity-test.sh <device name> <property>
To access released FESA3 Software the JAPC REST interface can be used: https://www-acc.gsi.de/wiki/FESA/Intern/JAPCRESTService