Skip to end of metadata
Go to start of metadata

Date

Attendees

Discussion items

Story reshuffling

  • moved some stories (mostly bugs) from overloaded "Refactoring" (DM-1030) to empty "Stability" (DM-1061)

Best practices

Qserv docs

  • related to DM-1792
  • we want to maintain old Qserv releases
  • problem 1: we depend on moving parts (lsst infrastructure, like newinstall.sh), which sometimes breaks our releases and invalidates documentation
    • would be good to discuss with Kian-Tat Lim, or via RFC, or maybe with DM team at AHM?
  • problem 2: now documentation is tied to a single git commit. Rely on branches and/or tags to overcome this.

Path to mysql credential file

  • came up in the context of Data Access / Metadata Store
  • pick file name and harcode it (e.g. .lsst.auth), check for it in default location (user home dir), allow overwriting location via envvar. Secure the file via standard acl.
  • this won't work for Qserv, can't write single config file that will serve all our needs, we connect from different places, from different tools, needs different privileges.

lsst-db2 access

  • open port 4040 for ipac, ncsa and slac, open ssh for everyone, close everything else
    • Jacek will talk to slac IT security
  • this came up because we want to run qserv as a service for SUI/ipac

Authorization in the long term

  • pushing authorization down to workers non-trivial, also, it forces connection per user (so potential scalability issues)
  • expose problems soon. Do exploration in S15: create "Qserv Authorization" epic. Limit exploration to 1 week. Work covered by the epic: explore doing authorization centrally. Use information generated by parser. Either generate dummy query and run on mysql that runs near czar, or use info produced by parser to determine if user is authorized
  • See  DM-1803 - Getting issue details... STATUS

DM-1035 (butler)

  • it is an empty epic, need to capture Kian-Tat Lim's work in story/stories

Geometry

  • Serge's part nearly done, will ask Jim and Fritz to review

Suggestions from Fritz based on past experience

  • 5 min daily standups, must be low-effort/high-visibility to succeed
    • optimization: special channel in hipchat ("Database Team Standup"), we post updates at least every day.
  • retrospective once per month, at the end of each sprint
    • everyone briefly says what worked well, what did not

Daniel away most of next week, at xrootd workshop