LDR Meeting April 23, 2004

Logistics

  • April 23, 2004
  • 9:00 am to 4:00 pm
  • MIT, NW22-220, Boston MA
  • hotel information
  • campus maps
  • Keith has requested that Marie have the doors unlocked from 8-10am so there shouldn't be any problems. As a backup, please go next door to Marie Woods office NW17-161 (NW17 & NW22 are adjacent) and she can call us to bring over stragglers.

People

Confirmed attendees so far:

  • Keith Bayer
  • Kevin Flasch
  • Mike Foster
  • Ben Johnson
  • Scott Koranda
  • Brian Moe
  • Hari Pulapaka
  • Murail Ramsunder

Agenda

  • 09:00 - 09:30 "LDR: Past, Present, Future" (Scott Koranda)
  • 09:30 - 09:45 "Better Metadata for LDR" (Brian Moe)
  • 09:45 - 10:00 "Plans for LDR Support" (Kevin Flasch)
  • 10:00 - 10:30 "Leveraging the DiskCacheAPI from LDAS" (Hari Pulapaka)
  • 10:30 - 10:45 break
  • 10:45 - 11:00 "Making Python Go Faster" (Hari Pulapaka)
  • 11:00 - 11:15 "Matlab, LDR, and Framequery" (Mike Foster)
  • 11:15 - 12:00 LDR feature requests (group discussion)
  • 12:00 - 01:00 lunch
  • 01:00 - 02:00 requirements/plans for S4/S5 (group discussion)
    • diskcacheAPI and data discovery/publishing interaction with LDR
    • publishing interface/API?
    • diskcacheAPI as a LDR storage module?
    • single LDR interface/API?
  • 02:00 - 03:00 prioritizing LDR development (group discussion)
  • 03:00 - 03:15 break
  • 03:15 - 03:50 draft plan document for LSC Comp Comm/DASWG
  • 03:50 - 04:00 plan summer meeting in Europe (UK?)

Known LDR Feature Requests

  • smooth upgrades with migration of metadata/RLS state
  • choice to use exisiting MySQL server
  • green/red light "at a glance" web page
    • gauge telling percentage of collections transferred
  • global scheduling across multiple sites/collections (think LLO going down during S3)
  • archived transfer peformance information
  • scheduling based on archived transfer performance information
  • on-the-fly configuration
  • rotating log files
  • validity checking at server and client end for transfers
  • "proxy LDR"; if a LSCdataFind request fails that ups the priority for the failed file?
  • Reliability of transfer features (I think 'validity checking' covers it).
  • Optimizing transfer speed within reliability and security needs.
  • Are we secure enough?
  • Optimizing the LDR database for data analysis (think pounding!). The mySQL server can take it (typically loads of 8-10), but our experience is that it kills the RLS server and LDR and that is why we had to set up a separate db for analysis on another server. Is this problem solvable?
  • (more coming...send to Scott Koranda)


$Id: meeting-042304.html,v 1.1 2004/08/05 15:12:54 skoranda Exp $
LDR Logo
Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.