Release of FESA Deploy-Units

Binaries and Configuration

Releasing a FESA deploy-unit means basically copying the binary and its configuration files to the dedicated FEC directory on the asl cluster. The configuration files must include a FEC-specific instantiation file which is used by the FESA deploy-unit.

                        |------------------> FEC1 
         DU ----------- |------------------> FEC2 
                        .
                        .
                        |------------------> FECx 

At this stage no distinction between operational and development environment is performed.

Accessability for Clients and Database Involvement

The interface of the FESA software (class design, deply-unit design, FEC instantiation) should be accessible for applications using a database. Each version of FESA software may be exported to the database once only. @GSI this involves since 2017 a database for productive purposes and another database for test- and development purposes.
During runtime of FESA software a dedicated CMW nameserver must be used in the dedicated environment.

Instantiations may be updated as often as required for each version of FESA software.

Sources

The sources of the FESA software should be stored in a repository for maintainability and traceability.

Information

For maintainability all the information (what, where, which versions, ...) should be stored in a database. An interface is required to add information to a database and to fetch information from the database.

Ideas

Instead of delivering each FESA software 'bundle' to a FEC from within the FESA Eclipse plug-in a central binary repository should be considered for operational FESA software at least.

The idea is to release operational versions of FESA software to a binary repository first. The FESA software should be stored in this repository depending on its version.

As a second step (apart from the FESA Eclipse plug-in?) the FESA software is prepared for the FECs it should work on. This step must involve the configuration of the instantiation files, which could be generated with help of the FESA database. A way for manipulation of these instantiation files prior to the release to a FEC must be foreseen, e.g. a web interface or a multiple file editor.

The FESA software should be spread to the FEC directories from the binary repository. Different versions of FESA software itself should be selectable so a rollback of an older version is possible as well.

Requirements

• spread FESA software binaries and its configuration (instantiation) on the asl cluster for FECs from a central binary repository
• tag FESA software sources in a repository
• create and manipulate instantiation documents for specific FECs
• setup of FECs (setup of required directories on asl cluster)
• maintain FECs, to add, to delete, to create new FECs, to rename existing FECs, ... -> database-based?
• maintain FESA software on dedicated FECs (delivery, update, rollback)
• update FEC database information during release, update, rollback
• configuration of the FECs for using the apropriate environment at runtime
• visualisation of FEC setups, installations, ...

-- SolveighMatthies - 21 Apr 2017