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
Topic revision: r2 - 08 May 2024, AlexanderSchwinn
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback