Version 0.4

With version 0.4 we are planning to replace the CouchDB backend of the Dashboard with probably ElasticSearch. Therefore more time is necessary, so we do not expect to see the release before end of Q2 in 2011. Owen Coutts will mainly work on that release during his internship.

Functionality

Front End

• Filter by:
  • Locale
  • OS
  • Build/Version (Ideally select a range)
  • Date
• Tag Bugs
• Linking test modules to the repository for easier investigation of failures

Application Server

• Deal with users
  • Ideally through LDAP so we don't have to roll a registration system
• Tag Bugs
  • Add/Change/Remove of bug numbers to specific failures
  • Add Comments

Elastic Search

• Connect River to backend storage

Backend Storage

• Map-Reduce Reports
  • failures/passes per function
  • Probably will require a different db/index

Tasks

Q1

• Define specs and requirements for the replacement dashboard
• Create an Elastic Search pilot application to confirm the expected functionality

Q2

• Update specs and requirements based on pilot application
• Implement features based on specs in multiple milestones
• Deploy application to production
• Hold a brownbag to present the new dashboard

Technical Background

Architecture

• Backend
  • Storage should be done with hadoop. Hadoop infrastructure is available and proven to scale. The decisions to move away from couch db was made because of the inability to scale and the concerns about the maturity of the software.
• Search/filtering dealing with data.
  • Elastic search has the capability to search/filter and use natural language to do so.
  • We will need to use some form of map reduce to deal with converting the data from lots of reports to aggregated functions.
• CRUD Server
  • Owen is using Django as a CRUD server (Create, Register, Update, Delete). This will allow us to give registered users the option to tag things/comment on them. We use playdoh on the web-dev team. This is a layer on top of django. We may ignore some features, for example localization (I assume we are not translating this app into other languages)
  • The crud server will also be used as a pass through into the firewall for the backend apps (elastic search and hadoop are behind the firewall)
• Front End
  • I will try to use something that has been used before. Likely, sammy.js views that allow for all the functionality listed in the functionality section.

Unknowns

• Results are currently received (and stored) based on the report they were submitted with. However, we want to show the user information aggregated per test function. This aggregation as well as filtering /searching (by local, language, operating system ect.) needs to happen in real time.
  • Ideally we would filter and search the data with elastic search and then run a map reduce in order to aggregate this data. The systems are not usually designed for this, elastic search doesn't output large quantities of data in real time (with the current database, looking through all data takes multiple seconds)
  • Another option is to duplicate all the data per function. We wouldn't have to map the data of reports to functions in that case but we would have a much larger database with a lot of extra data in it.
  • Use only hadoop with map reduce. This would involve having inflexible views that will not be easy to tweak over time.

Progress

Prototype

• Proof of concept to show that at least the same functionality can be rolled with elastic search.
• Technical Knowledge learned can be found here: Proof of Concept Prototype

Next Steps