Meeting 2017 05 04

• Time: 10:15 - 12:10

• Participants: Tim, Matthias, Lennart

• Discussion how we want to organize our meetings: recap ToDos, fix TO, discuss individual items

• Tim:

  • It is unclear wether we get a realistic IMAP log, would be really awesome
  • We will create an extra pluto-verification repository

• Matthias:

  • Researched about ways to export data from Prometheus for scientific data sets
  • Looked into ways to (efficiently - noop) monitor and inspect pluto
  • Will exchange pluto's logging with gokit-logger
  • Thought about how to possibly scale pluto at runtime - difficult! Fixed config, stateful workers.

• Lennart:

  • Set everything up online, gave access etc.
  • Started to look into verification with Isabelle/HOL
  • Looked into imaptest - we should not focus too much on it

• Contributions

• Runtime scalability

  • pluto as of right now is fixed at runtime, it is not elastically scalable
  • Different possiblities to approach this, very soon physically limited
  • Could be very hard to already implement it directly, but conceptually very promising
  • Research state-of-the-art: How do systems as Cassandra, Aerospike, etc. do that?
  • We will meet explicitely to think about and discuss this issue

• Deployment

  • We will try to test locally before going into a public cloud

• Verification

  • Not trivial, we need to very clearly define our scope
  • We will first try to write down the structure and idea of the proof before attempting to proof it in Isabelle/HOL

• ToDos until 2017-05-11

  • Lennart:
    • Review and prioritize contributions
    • Create the extra pluto-verification repository
    • Engineering-Board: implement own items
    • Look further into verification: Isabelle, Peter's work
    • Check CRDT variant alternatives
  • Matthias:
    • Review and prioritize contributions
    • Engineering-Board: implement own items
    • Include metrics and logger into pluto packages
    • First steps in pluto deployment with e.g. Minikube
    • Check how other well-known distributed systems (Cassandra, Aerospike, etc.) solve (or not?) the runtime scalability issue
  • Tim:
    • Lead proposal: review and prioritize contributions
    • Try to reserve some hardware resources in EN basement (check if we will have sufficient privileges)
    • Apply for Google grant
    • Verification idea in blue paper in new repository
    • Think about runtime scalability (timeplan)