Requirements new Deployment System

NFS is not supported for the Yocto PPC Image, and as well is supposed to be replaced for Fesa deployment.

So we need a new way to deploy software on FECS.

This Wiki page is supposed to collect requirements for this new deployment system.

Requirements can be tagged with:

• [stage0] = An absolute must-have
• [stage1] = Convenient feature, which should be available in the first version
• [stage2] = Nice to have, can be added later on, if there is time

So far we agreed on using a web-location to store FEC software and to download it during FEC boot via wget or curl.

• [stage0] One folder per FEC on the web-storage (web-storage-base/fecs/[FEC]), containing a "init" folder which has the scripts, currently provided on /common/export/nfsinit/[FEC]
  • Like now, on boot the FEC downloads that init folder and executes all scripts (possibly symlinks) found there
  • Like now, there will be a web-storage-base/fecs/global to store scripts which can be re-used
  • Like currently, these scripts trigger the download of the correct equipment-software and will start it via dbus-dameon
• [stage0] Files are compressed
  • All binaries/libraries/config-files/etc. below web-storage-base/software/[software]/[version] and the other folders shall be compressed. That has two advantages:
    • Less disc space required
    • The unpack location can already be defined during compression. So the FEC scripts don't need to know where to place things.
  • Which compression format to use ?
• [stage0] Separate folders on the web-storage containing equipment-software:
  • web-storage-base/software/[software]
  • If the same software is used on multiple FECS, there is no need to duplicate the binaries per FEC --> less disc-space occupied
  • Each FEC has a software folder (web-storage-base/fecs/[FEC]/software), containing symlinks to the concrete software which is to be downloaded by the FEC
    • The symlinks have to point to a concrete Version of the software (compressed archive)
• [stage0] FEC specific folder for configuration
  • web-storage-base/fecs/[FEC]/configuration
  • Inside there compressed archives can be found (or symlinks to them), will be downloaded and unpacked during boot
  • web-storage-base/configuration keeps config which is identical for multiple FECs
    • Inside there, fesa instance file names should be versioned, to know which FESA binary version matches to them.
• [stage0] Deployment Automation in Fesa and devacc
  • In devacc calling "make install" on the according project should compress and copy stuff to the right location
  • In FESA, the existing "yocto-fesa3" could do so. (As well the fesa-eclipse-plugin should deploy via that script)
  • Dev-releases of e.g. Fesaclasses per default should not be installed to the webserver, they should be directly copied to the FEC (as well as compressed archive)
• [stage1] Multiple equipment-software versions in parallel, in order to allow an easy swap if there are regressions
  • web-storage-base/software/[software]/[version]
  • Maximum 3 productive versions in parallel to don't mess the disk too much
  • On release of a new productive version, older versions need to be removed. (Check if they are unused!! Symlink from FEC to software?)
  • version "dev" is used for dev releases. (usually should not be needed, since dev releases should be directly copied to the FEC)
  • If a dev release is used by a FEC, it will not be started as dbus-dameon after boot /during 'init' phase (actually might make sense to run dev releases via daemon for long-term tests)
• [stage1] persistency
  • Some FESA classes do have persistent data, which shall survive a reboot
  • A central service/cronjob should copy that data from FECS using persistency in regular intervals and store it compressed in a dedicated folder: web-storage-base/fecs/[FEC]/data
  • On boot of the FEC, all items in the data folder are downloaded and unpacked
  • Only fesa classes which do use persistency should have such a 'data' folder
  • The central service will only persist data of FECs which do have a 'data' folder
  • Maybe the folder should be called 'persistent-data' to make the usage more clear?
• [stage2] A service could orchestrate the release
  • Requirement raised by C.Handel
  • copy files into the correct web-storage-base/* folders
  • On pro release, update the database accordingly
  • reboot the FEC or restart the service, if required (service has special permission, so that no password needs to be typed)
  • Specialized for Fesa releases / no devacc support
• [stage2] Monitoring (Possibly a bit offtopic here)
  • FECS which are to be monitored by icinga could have a folder web-storage-base/fecs/[FEC]/monitor
  • Inside that folder, services which are to be monitored on that FEC could be defined (to be checked in which way)
  • A file (or subfolder with files?) "monitoring_groups" could define the icinga host-groups in which the FEC should be listed
  • All that could be automatically filled during a productive fesa/devacc-release