Skip to content

Meeting 13 February 2018

Sebastian Fehlandt edited this page Feb 13, 2018 · 23 revisions

Participants

  • Alessandro Caproni (ESO)
  • Filippo Fagioli (ASTRI/CTA)
  • Sebastián Fehlandt (Inria Chile)
  • Jazmine Maldonado (Inria Chile)

Topics to discuss

  • Identifier of SINK core nodes like the WebServerSender or the Cassandra client
    • IMO they should have a unique Identifier like other core clients but with no parent like the Supervisor
    • should send the heartbeat like other tools will do
  • Once we have the heartbeat in place we should probably have a tool that checks the healthiness of the alarm system and provide alarms by means of ASCE/DASU as usual. If something is wrong an alarm should appear in the user panel
  • Is it time to start thinking of the production? We should have a kind of checkbox for main subsystems where the user presses to have details
    • one box can be the weather station
    • one box can be the status of the alarm system
    • ACS
    • ...
  • Is it possible to have a tabular view of alarms automatically generated with filter capabilities?
    • no filters shows everything
    • filter (regular expression?) shows only the alarms whose identifiers matches with the given regular expression
    • Inria: We can add filters to current table as a first step. Then we can add preset filters for each different system. Then we can create the main overview where each subsystems is linked to a set of filters in the table view. (Create tickets for this)
  • Preset table of alarms would also be useful (the identifiers to show in the table given in a text file)
  • Is it time to start thinking of how to show new alarms and allow the user to ACK? A light version without recursion would be fine at the beginning
    • Shelving?
  • How can we parse the Weather Station timestamps?
    • Inria will send examples of the timestamps to request info.
  • Should we lower the logging level in production? DEBUG seems to be too much
    • Yes, this can be done in the CDB

We will create tickets out of the points to discuss and I would like to fix the milestones for the next release, considering that the core, sever and displays (could) have a different life cycle. Still, we can make the next release all together: what about the end of February?

  • As a minimum, issue #63 and #58 would be my next task but they can be more time consuming than expected

Ale´s worklog

  • Issue #52: finally fixed
  • prepared release 1.0.0 of the core, including API docs
  • Asked Jonathan for a laptop/pc to show IAS panels in the OSF control room
  • Core updated to python 3
  • IAS provides user friendly scripts to start supervisors and converters (Issue #62)
  • Renamed packages to avoid references to prototype (Issue #45). Should you better refresh your installations with the trunk of the develop branch?
  • Asked a ALMA VPN account for Sebastian IT-26911. ALMA policy is to have only personal accounts. Shall I ask accounts for the others as well?
    • Yes, please, one for Maximiliano and one for Jazmine as well.

Inria Chile's worklog (current and last week)

  • Refactor of IAS Webserver in order to remove the unnecessary Alarms database and replace it by an in-memory data structure
  • Upgrade of Webserver's Django Channels to versions 2.x.
  • Prevent AlarmWeatherStationPlugin from crashing when data cannot be retrieved from the Weather Station
  • Releases:
    • IAS Webserver
    • IAS Display
    • IAS Plugins
    • Integration Tools

Filippo´s worklog

  • Talk about the meeting of this friday in Bologna;
  • Improve the plugin class, now still in local but soon i'll upload it;
  • Start working on issue #48.

Next Steps:

  • Inria Chile:
    • Finish refactoring Ias Webserver, issues #14 and #16
    • Preliminary model of ack and shelving for Webserver
    • Start thinking about Display architecture with overview/chessboard.
    • Send timestamps from Alma Weather System to Alessandro,
    • Rename ias-plugins repo to ias-contrib, with subfolders (coordinate with Filippo):
      • Plugins
      • Transfer functions
      • Plugins filters
    • Improve current table in Display with filters, and then presets of filters, issues #10 and #11
    • Update Validity calculation in Webserver and Display, issue #17
      • Consider global refresh rate + tolerance form CDB (does not depend on IASIOs anymore)
      • For Display we can still recalcuate on each "list" request from Display
    • Display with overview/chessboard: #12
    • Implement ack and shelving in WebServer (and then display)
    • Provide login and authentication/permissions (Display and Webserver)
  • Alessandro:
    • Add list of fullRunningIDs from every input of a Dasu's output. In order to give dependencies to Webserver (create issue)
    • Heartbeat and command
    • Issue #63
    • Issue #58
  • Filippo:
    • Issue #48
    • Start looking into Maven repository

Clone this wiki locally