Release and Run FESA Software

To provide the FESA software for testing purposes or 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.

NOTE: 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 ( vmla01 / scuxl0001... )

Release

The state of a FESA class and the FESA deploy-unit is defined in the XML element "information/state". If this state is set so a value different from 'operational', a development release will be performed. 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).

1. 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
2. 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)) .

State: operational

Renew the kerberos ticket prior to an operational release : https://www-acc.gsi.de/wiki/FESA/FESA3FAQ431#Why_does_SVN_require_a_password_during_the_release_of_operational_FESA_software_63_45_62_ACC_Login_40kerberos_41

If an operational 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.

The settings in the FESA expert preferences will not be considered. If available FESA class documentation will be uploaded to the webserver. The FEC 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 ->../global/fesa_64bit_pro_environment         # CMW nameserver of development 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 (operational) environment. See this section for details.

State: development

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

 --env="CMW_DIRECTORY_CLIENT_SERVERLIST= cmwdev00a.acc.gsi.de:5021

This parameter is used in the FESA environment launch script /common/export/nfsinit/global/fesa_64bit_dev_environment .

State: inUse

So far (until 03/2017) this state was unused @GSI. From FESA3 4.2.0 on this state is used to indicate a state in which a FESA deploy-unit already was operational 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.

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

 --env="CMW_DIRECTORY_CLIENT_SERVERLIST= cmwpro00a.acc.gsi.de:5021

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.

Run

Automatically

• 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> .
• SSH to the FEC (for the password please refer to CSCOIN)

user@asl7xx:somewhere>ssh root@scuxl0123

• reboot the FEC

[root@scuxl0123 ~]# reboot now

• login again and check which binaries are running

user@asl7xx:somewhere>ssh root@scuxl0123
[root@scuxl0123 ~]#ps -a

• More information about the libslack daemon used to run the FESA software can be found in the libslack daemon man pages.

Manually

• SSH to the FEC, e.g. ssh root@scuxl0123 # Please refer to the FESA team or CSCOIN 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 asl cluster (asl740..asl744)

Release

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 directory.

Run

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

Productive asl cluster (asl340..asl344)

Release

The procedure for the productive asl cluster is identical to the release procedure for FEC's.

Run

Similar to the development cluster root rights are restricted.

JAPC Client Access

Database Entries

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

FESA3DBInformation .

Please note that these tools are not yet adapted for distunguishing between the productive and the development database.

RDA/CMW Test

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>

or

/common/usr/fesa/bin/device-connectivity-test.sh <device name> <property>