===Profile Information
Name: Amey Parundekar
IRC nickname on Freenode: thelostexplorer
Web Profile: https://www.github.com/the-lost-explorer
Location: Pune, Maharashtra, India
Typical working hours: 11am to 6pm (Indian Standard Time)
===Synopsis
Wikimedia uses over 200 MariaDB instances to store content and metadata for Wikipedia and other free knowledge projects. While standard open source tools for both monitoring and automation are used when possible, there are some tasks that require custom development. For such monitoring tasks, there is a necessity to replace the existing database supervisor “Tendril” with a faster one that takes advantage of (or integrate with) modern technologies available at Wikimedia such as prometheus+grafana metrics monitoring, performance_schema, pt-heartbeat, or our database backup system.
This project aims at making a supervisor (we can call it a dashboard/monitor) for monitoring the status of all the Wikimedia database instances.
- Possible Mentor(s): @jcrespo
- Have you contacted your mentors already? Yes
===Deliverables
====This project will aim to deliver a web-based application to monitor the database status.
This contains:
1. A tree view of all the database instances.
- This will show a horizontal tree view of the instances as opposed to the top-down tree approach used in dbtree.
- Each node of the tree will consist of information related to the database instance viz.:
- Database instance name(identifier)
- Lag
- QPS
- Version
- Binlog
- Read/Write permissions
- Latency
2. A table view of all the database instances.
- The table can be adjusted to show information sorted by instances as well as servers.
- It will also have a global search feature.
- It will include the following columns:
- Instance
- Section
- Location
- Server
- IP address
- Port
- Version
- Uptime
- Pool
- QPS
- Latency
- Lag
- I/O status
- SQL
- RO
3. All the columns will be sortable(and optionally searchable) by clicking on the heading.
4. Clicking on any row will show a Modal (Pop-up) with all the information available about that server/instance.
5. It will use iconography and color gradients for rows where necessary for easily pinpointing important information since the table will provide too much information.
- If a server/instance is down, the row becomes maroon.
- If any server/instance has no SQL support, the row becomes yellow. Note: The above feature is very necessary for better UX.
6. Option to export table information into comma-separated values.
7. Feature to change the update frequency of the table. (Can be set to a custom period)
====Optional features (to be implemented if time permits)
1. Grafana-like metrics for a quick view of the database status.
2. An intelligent feature that analyses the database instance failures, making it easier to find out the source of failure.
3. Integrating GraphQL for ease of maintenance.
4. Dockerizing the application for ease of deployment.
===Participation
1. In my opinion, since we are starting from scratch, we shall make a new GitHub repository (or on WikiMedia's local git system).
2. I shall submit PRs to this repository.
3. For sharing status, I will use Phabricator. Shared Google Sheets can also be used.
4. I will share my experience on Medium on a timely basis.
===About Me
- **Education (completed or in progress):** Final year (4th) undergraduate student at Vellore Institute of Technology, India
- **How did I hear about this program?** GSOC website
- **Will I have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program?** **None.** No other commitments during GSOC period.
- **We advise all candidates eligible for Google Summer of Code and Outreachy to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?** I am only applying for the Google Summer of Code with Wikimedia organization.
- **What does making this project happen mean to me?** Making applications is something I have always enjoyed ever since I have sailed the application development boat. I always strive to make things minimal and developing useful minimal applications gives me immense pleasure. Since I understand and cherish the power of open-sourced development, developing an application for Wikimedia would fill me with extreme pride for having contributed to something that helps or supports technology used by millions.
===Past Experience
I am listing only application development related experiences. (I have experience in the field of electronics as well but it would be irrelevant here)
All of the projects are available on my GitHub profile.
1. Project SHELF: A website for selling books, made solely for universities. This was made as a part of my internship with Hasura (https://www.hasura.io)
2. Project munverse: A chatting application made specifically for Model United Nations. It was used by over 1000+ people at MUN in my university.
3. Navi: An Augmented Reality based navigation system made using Google Maps API and Google ARCore.
4. DWAC (Distributed Wireless Ad-hoc Computation Simulation): A simulation software for distributed wireless ad-hoc networks made for my wireless communication course.
5. Lily: A tkinter based application to find beautiful natural patterns with geometry based on origami.
6. iClaimNet: Generation of a large scale dataset using natural language processing for analysis of fake news on social media. Also published a paper on time.
7. simon: A game written in assembly language and C made to run on 8051 microcontrollers.
8. Research and Development Internship at PTC. (Product Lifecycle Management)
9. Full Stack Development Internship at GMetri Inc. (AR/VR) - on-going and ends in April 2020
10. One of the founders and board members for an AI Research forum at VIT. (https://ai-vithink.github.io)
11. Teaching Assistantship at VIT for microcontrollers.
12. Certification from India Institution of Technology, Madras for modern web application development.
===Timeline
> May 4, 2020 - May 14, 2020 - Community bonding period
1. Knowing more about WikiMedia’s databases and Tendril.
2. Survey to know exactly how sysadmins want their dashboards to look like. (can be verbal or more conveniently a Google Sheet.)
3. Explore and discuss possible technologies that can be used for the creation of the software.
4. Design a final mock-up for the application, get approval from mentor possibly a few sysadmins.
> May 15, 2020 - May 22, 2020 - Playing with the database
1. Understand the database.
2. Design queries to get the relevant data from the existing database.
3. For the table.
4. For the tree.
5. Optimize queries and remove any redundancy.
6. Identify what data the queries will provide.
> May 23, 2020 - June 7, 2020 - Writing APIs
1. Understanding APIs necessary for the application.
2. Writing APIs for the table view. (access and data)
3. Writing APIs for the tree structure. (access and data)
4. Figuring out the optimum structure for the output response of the above APIs.
5. Roughly, the Tree’s API must be a JSON which follows a breadth-first-search friendly structure. (the final endpoint will be something like `getTreeData`)
6. Roughly, the Table’s API can have a simple JSON array output with rows of the table. (the final endpoint will be something like `getTableData`)
7. Polishing the API response and adding possible authentication measures.
> June 8, 2020 - June 21, 2020 - Developing the Table
1. Making a basic table component suitable for the information that we will use. (personal choice: Making React Components but can be simple HTML+CSS as per requirement)
2. Making the Table structure available at an endpoint.
3. Binding the table with data using API previously made.
4. Making the modification to the APIs if necessary.
5. Adding searching, sorting and other features listed in the “Deliverables” section for the Table.
> June 21, 2020 - July 7, 2020 - Developing the Tree
1. Making a basic tree component suitable for the information that we will use. (personal choice: Making React Components but can be simple HTML+CSS as per requirement)
2. Making Tree structure available at an endpoint.
3. Binding the tree with data using API previously made.
4. Adding features listed in the “Deliverables” section for the Tree.
> July 7, 2020 - July 14, 2020 - Polishing
1. I shall use this time, to remove redundancies, making the UI user friendly if already not and understanding flaws.
> July 15, 2020 - July 19, 2020 - Testing
1. I shall test the application in every possible way. That includes:
2. Performance Testing - Number of users, type of devices
3. Integration Testing - To make sure everything works well with the existing infrastructure.
> July 20, 2020 - July 27, 2020 - Implementing optional/ additional features
1. I will use this time to implement the optional features as listed in “Deliverables”.
> July 27, 2020 - August 7, 2020 - Documentation
1. This time will be used to document everything related to the application:
- API documentation
- Usage documentation
===UI Mock-ups
I shall use the mock-ups as posted in [T246435](https://phabricator.wikimedia.org/T246435) as the mock-ups for the application. (See below)
{F31648100}
{F31648107}