1 / 15

ALMA Integrated Computing Team Coordination & Planning Meeting #1 Santiago, 17-19 April 2013

ALMA Integrated Computing Team Coordination & Planning Meeting #1 Santiago, 17-19 April 2013. ICT Group planning: Observatory Interfaces / ObOps M Chavan. ObOps group resources. Bhola Panta , NAOJ 50% Robert Kurowski , ESO 100% Rodrigo Tobar , ESO 100% (but…) ???, NRAO 50%

daktari
Download Presentation

ALMA Integrated Computing Team Coordination & Planning Meeting #1 Santiago, 17-19 April 2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ALMA Integrated Computing TeamCoordination & Planning Meeting #1Santiago, 17-19 April 2013 ICT Group planning: Observatory Interfaces / ObOps M Chavan

  2. ObOps group resources • BholaPanta, NAOJ 50% • Robert Kurowski, ESO 100% • Rodrigo Tobar, ESO 100% (but…) • ???, NRAO 50% • Maurizio Chavan, ESO 90%

  3. R10.0 to-do (as of Apr 4) • Freeze date Apr 26 • Mostly Project Tracker features • More info, plotting, Co-I access • Some AQUA work • QA1 bits depend on Control • Some infrastructure work • Issue: Rodrigo away for a long time

  4. R10.1 to-do • Freeze date May 24 • Phase One Manager for Cycle 2 • AQUA • QA2 • Plotting, trending • Alarms for degraded performance (trending) AQUA requirements are not detailed enough for implementation

  5. Post R10.x to-do • AQUA: old, left-over requirements • QA0 plotting/trending, to be completely reviewed • General Statistics Tools, just a title • Life-cycle: detect internal inconsistency • ProTrack, Ph1M, infrastructure • a handful of nice-to-have features Our users don't really seem to need much from us right now

  6. What do we do after R10.1? • Phase One Manager: cope with July test feedback • Other tools: new requirements will come • For sure! • New development

  7. New development after R10.1 • OMC Reload • Re-focus on OSF Operations support • Project Tracker Reload • Separate the "PI View" from the current tool • (Web) Shift Log Tool Reload • Add "write" capabilities • Observatory Characteristics Database • Create and offer management tools

  8. OMC Problems • Many “OMC Problems” are not OMC problems at all • Some displayed info is not trustworthy • E.g. destroyed arrays are shown as still up • Marcus thinks this (threading) issue is solved • OMC monitors devices via SNMP, but configuration is out-of-date • Competes with CACTI, ZENOSS, PRTG

  9. OMC-related Problems • Nobody in ICT in charge of global display • Full System Restart procedure is not supported • Operators do it differently, possibly incorrectly • Need FSR display with all restart-related info • VLT has visual tracer (wizard) supporting a mixed automated/manual procedure • Antenna config info not available • Dashboard 1.0 uses separate database

  10. OMC Reload • ObsIF project, contributions from all subsys • Provide single ICT point of contact to DSO • Overcome the artificial OMC/Panels split • Consider global display issue • Provide support for FSR • Dedicated display, guided procedure • Complete on-going development • Integrate with Dashboard 2.0

  11. Project Tracker Reload / 1 • Split between Staff- and PI View • Staff View ("for DSO") • Redesign GUI, better use of screen space • Remove all PI-View-related if statements • Merge with AQUA • Extensive refactoring

  12. Project Tracker Reload / 2 • PI View ("Community Edition") • Re-architect as client + server • Lightweight client with slick GUI (tablet?) • Stateless REST server • Re-use as much code/ZUL as possible • But not more than that • If needed, keep in sync with PT for DSO • Introduce profiling infrastructure

  13. PI View Architecture

  14. (Web) Shift Log Tool Reload • Desktop Tool • Harvest log files into Shift Log Tool database • Separate views for Operators / DSO staff • Include all system configuration changes • Web client: add write capabilities • Where? Replication issues • Who? Permission issues • What? Write/edit/comment any entry; or provide dedicated DSO view

  15. Observatory Characteristics DB • Conceptually simple • Data in, data out; no processing • Simple data structures • No complex GUIs, reports • Ideal test case for Grails • Issue: requires Grails installation for building • Who is going to maintain OCD contents?

More Related