gsoc-2020.md.bak

---
layout: default
---

# GSoC 2020 Project Ideas

LazyWolves is super excited to announce that it will be applying to **Google Summer of Code**
for the year **2020** as a mentoring organization. LazyWolves is an extremely new organisation and it is really a very big and
exciting step for us. We will be immensely happy and delighted if we get a chance to participate
in this awesome event that Google organizes and bring more contributors into our organisation.

This page contains some ideas for GSoC 2020 that participating students might want to checkout.
Even if we do not make it to GSoC-2020, we believe that the below ideas will be really fun to work
on. Also these ideas describe the next steps in the respective projects.

## Auto registration of backends with ElasticPyProxy using agents

The aim of this project is to implement an auto **registration/de-registration** process which
will allow backend hosts to get automatically registered or deregistered with [ElasticPyProxy](https://github.com/LazyWolves/ElasticPyProxy/)

ElasticPyProxy is a system for flexible management of HAProxy backends which can autoscale. It allows dynamic
addition and removal of autoscaled backends from HAProxy without restart/reload of HAProxy. More details can be
found in the documentation of the project.

Till now, the backend discovery, registration and de-registration happens in a centralised manner. The host/server
running ElaticPProxy is responsible for discovering the live target backends and reister them with HAProxy and at the
same time, discover dead, state backends and remove them from HAProxy. The primary objective of this project
is to convert this centralised system to an agent based system.

An agent will run on every backend. Whenever a new backend comes up, the agent should fire a registration api call
to the ElasticPyProxy instance with whom it wants to register itself. Once the call is successfull, the  EP2 instance should register the respective host with itself and make it live.

Similar to registration API call there should also be a de-registration or self-removal API call. When an agent
from a backend will hit this API call, the EP2 instance should remove this host from the active backend pool.
Since backends can be ephimeral, this will be necessary when a backend server is going down (may be a scale down
activity).

Both the registration and removal API calls should be compatible with ```update_by_runtime``` and ```update_by_reload```
methods of backend addition.

As far as the agent is concerned, it can be a separate standalone application altogether, or it can be the
EP2 application itself which will be given the capability to run in agent mode. This part can be taken up
by the student to decide and discuss with the mentor.

### Expected outcomes

- An EP2 agent for registration and removal of hosts from EP2.
- Proper test suite for the same.

**Skills preferred** : Python3, Concepts of load balancers, basic to intermediate experience with HAProxy.

**Possible mentors** : Deepjyoti (djmgit)

**Difficulty** : medium

## Enhancing SaberX and creating status endpoint and statistics endpoint for SaberX

This project has multiple parts. The overall aim of this project is to enhance the functionality of
[SaberX](https://github.com/LazyWolves/SaberX). The various goals of the project are mentioned below.

### Creating a Status endpoint for SaberX

The Status endpoint should return status/state of the varuous triggers being used. The state of a
trigger should indicate, whether it is in fired state or not. It should also show if the action
associated with it was executed successfully or it faced any issue. Also it should display whether
the trigger itself has faced any exception.

In order to achieve the above goal, there should be a way to store the state of a trigger as soon
as it is evaluated along with informations like:

- Exceptions faced by trigger if any
- Timestamp of evaluation/fire
- State after evaluation (Fired state or normal)
- Actions executed successfully ot not, exeception if any

In order to store the above state information, any minimallistic python based Datestore like
[pickleDB](https://pythonhosted.org/pickleDB/) or [TinyDB](https://tinydb.readthedocs.io/en/latest/)
can be used. Since we dont require advanced database operations, the above databases make sense.
However, choice of db is open to discussion.

Once the database is decided, we require a handler library for the database. This handler library
should act as a abstraction for the database control. Hence, we should be able to change the backend
database easily anytime just by updating the handler methods.

Once database and handler library is in place, the api endpoint can be built on top of it. The response
type can be preferably ```json```. Also the API can be exposed over normal TCP sockets or HTTP (Open to
discussion).

### Creating a statistics endpoint.

This endpoint will provide the number of times individual triggers have been fired, number of times a
trigger has faced exceptions. Number of times the corresponding action has been executed successfully,
etc. This endpoint should allow filters like date or time range to fetch statistics between.

### Other enhancements.

The student should also try to work on the open issues during the community bonding period to get
aquainted with the project.

This project contains multiple parts and some might be time taken since it will require proper
structuring and design. Quality will be appreciated over quantity hence the completion of the
parts is subject to time.

**Skills preferred** : Python3, Knowledge about system monitoring (basic), Document based or key value based datastore, API programming in Python.

**Possible mentors** : Deepjyoti (djmgit)

**Difficulty** : medium

## Creating a cli client for Vision and solving open issues in Vision project

The aim of the project is to enhance [vision](https://github.com/LazyWolves/vision) as a tool to provide useful insight into the state of a server at the same time create a CLI based client for the same.

At present Vision only allows us to view file resources over http via browser. The [doc](https://github.com/LazyWolves/vision/blob/dev/README.md) describes the usecases for this feature and the different
options provided by Vision. In short it provides us the utilities of ```head```, ```tail``` and ```grep```
commands in linux over http. For example Vision can be used quicly view the last 50 lines of a particular
log file present in different servers, simply using the browser rather than logging into each server
over ssh.

The client should be able to accomplish the following goals:

- User should be able to view different log files from a given server using the client from the terminal.
- All the options provided by Vision should be provided by the client too.
- One of the primary feature that should be provided by the client is the ability to stream log
  rather than viewing only a fixed number of lines from the files.
- Viewing basic system metrics
- Viewing the processes running on the remote system.
- View services running on the remote system and their status.

Log streaming might require considerable change in existing server. Also the implementation of
system metrics, processes and services part will be dependent on the following issues:

[#15](https://github.com/LazyWolves/vision/issues/15), [#16](https://github.com/LazyWolves/vision/issues/15)
and [#17](https://github.com/LazyWolves/vision/issues/17)

Hence the above issues needs to be addressed before implementing their counter parts in the client.

Once the client is done, a number of utility features can be built on top of it :

- Querying muliple servers for a particular metric for comparision purposes.
- Finding out top n servers with respect to a particular metric.
- Finding out servers on which a particular process is running
- Comparing the state of a service on different servers.

This project contains a number of parts and the student can also surely come up with his/her own
ideas to enhance Vision. That would be actaully awesome!!. However as the time of this program is
limited, the completion of the above mentioned parts will be subject to time. Quality of the work done,
code design and structuring will be appreciated more than the quantity of work done.

### Expected outcomes

- Solving the open issues in Github as mentioned above.
- A CLI client for Vision with as many of the above features implemented as possible in the given time        frame of GSoC-2020.

**Skills preferred** : Golang, API programming in Golang

**Possible mentors** : Deepjyoti (djmgit)

**Difficulty** : medium

## Creating a centralised web app for Vision

The aim of this project is to create a centralised webapp for visualising and managing all the nodes
in a infra having Vision installed in them.

The webapp should have features to view remote file resources on a selected node, view system metrics (as
of now only cpu and memory is implemented.), processes runnning in the system and details and status of
any selected process, systemd servies running on the system, their status and option to start, stop,
restart and reload those processes and view journalctl logs and other system logs.

The app will act has a centralised dashboatd for quickly querying and visualising the current status
of the serber and the various components running on them. It should also provide feature for registration
of new agents/nodes.

Once the basic Webapp is completed and running, the student is recommended to work on implementing
further features on the agent side so that they can be exposed via the Webapp, if time permits.

This project will be done entirely from scratch, the student will be free to chose the stack of his
own post discussion with the organisation. He or she must be able to justify why the given stack is
being considered.

### Expected outcomes

- A centralised, simple and easy to use Webapp for managing all the Vision agents.

**Skills preferred** : Any suitable web technology for backend and frontend, for eg : 
                       Backend: Flask/Django(Python), Express (NodeJS), Golang
                       Frontend: AngularJS, Angular2 or upper, ReactJS, EmberJS.

**Possible mentors** : Deepjyoti (djmgit)

**Difficulty** : medium