Attendees: Andy H., Douglas, Fabrice, Daniel, Serge, Bill, Jacek


Integration cluster at IN2P3
  - have 50 nodes (part of the 300-node cluster)
    until end of 2013, then will go away, too old
  - IN2P3 wants to buy new small cluster for Qserv tests
    - ~one rack would make sense, o(50) machines
    - realistic spec that'd be useful (and relatively cheap):
       - not many cores, eg two 4-core CPUs (8 cores total)
         good enough
       - drive per core, so 8 local drives
       - we don't want any RAID
       - 1TB drives, or 2TB if cheap enough
       - 2GB RAM per core

GLADE / EXTASCID
  - (more at http://faculty.ucmerced.edu/__frusu/)
  - interesting, but complicated
  - not more parallel than Qserv
  - might be useful to package lsst benchmark, including
    queries and data and give to try to the GLADE developers
    - we need to destroy scientific value of the data
      before publishing (check with Mario?)
  - schedule mtg with the key developer, 1-2 h
    - might turn into some sort of collaboration


new xrootd client
  - 70% complete
  - can't try yet
  - server side approaches stability
  - ~abh/xssi/xrootd/source/xrd/ssi
     - would be useful to look from api perspective now
  - ready to try ~November
  - not entirely clear if we should migrate when available,
    or as part of the larger code rewriting


code refactoring / rewriting
----------------------------

very important to focus on tests
  - automated test bed, with buildbot
    - new metadata and new parser broke it
    - some queries don't work
    - work in progress to get that fixed now
  - buildbot will rebuild everything, takes ~20 min now
  - now buildbot runs on every commit to the master,
    but no more than 1 per day

  - plus larger scale tests (daily? weekly?)



proxy/lua
  - would be cleaner if we didn't use it
  - could try to link directly with mysql code
  - the new connect engine not ready yet


Need to arrange a wiki trac account for Andy H,
he will be more involved in Qserv coding now,
not just XRootD


documents ideas, everyone should read ahead of mtg,
and come to design discussion prepared


logging
  - want distributed logging with ability to query
  - key/value flexibility would be very handy
  - need to look from perspective how difficult it'd be
    to migrate away if our tool of choice goes out
    of fashion

Start with:
  - defining modules, interfaces


Draw a block diagram [Daniel]
  - start with higher level, show to Bill or Andy,
    drill deeper if needed
  - need before hackathon (mid Nov)


Jacek

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1