From Fedora Project Wiki
Line 80: Line 80:
As it is mentioned in the [https://pagure.io/fedora-commops/issue/105 pagure ticket] which is referred on the project idea, this can be achieved through statscache to build a central generation system for Fedora. Statscache consumes all the messages and does not query datagrepper every single time thereby increasing the efficiency. While building on top of statscache the number of scripts used to get the data can be significantly reduced to almost zero.
As it is mentioned in the [https://pagure.io/fedora-commops/issue/105 pagure ticket] which is referred on the project idea, this can be achieved through statscache to build a central generation system for Fedora. Statscache consumes all the messages and does not query datagrepper every single time thereby increasing the efficiency. While building on top of statscache the number of scripts used to get the data can be significantly reduced to almost zero.
In this project, three types of plugins are required one for the statistics by FAS groups, one for the statistics based on badges and the last one for the statistics based on FAS trend. When a message arrives at statscache, a fedmsg consumer receives it and hands a copy to each loaded plugin for processing. Each plugin internally caches the result of this message for processing untill a polling producer instructs it to update its database model and empty  its cache.. So, if we want a new kind of statistics to be kept, we need to write a new plugin for it. To get statscache to load and run plugins, include its class as an entry -point under statscache.plugin in the package’s setup.py .  
In this project, three types of plugins are required one for the statistics by FAS groups, one for the statistics based on badges and the last one for the statistics based on FAS trend. When a message arrives at statscache, a fedmsg consumer receives it and hands a copy to each loaded plugin for processing. Each plugin internally caches the result of this message for processing untill a polling producer instructs it to update its database model and empty  its cache.. So, if we want a new kind of statistics to be kept, we need to write a new plugin for it. To get statscache to load and run plugins, include its class as an entry -point under '''statscache.plugin''' in the package’s '''setup.py'''.  
 
[[File:Screenshot_from_2017-04-02_23-33-33.png]]


Diagram explaining how the whole process will take place. From the creation of plug-in to integrating it with the web application.
Diagram explaining how the whole process will take place. From the creation of plug-in to integrating it with the web application.

Revision as of 14:16, 3 April 2017

Contact information

Why do you want to work with the Fedora Project for GSoC ?

Contributing to Open Source interests me and I make my contributions through Fedora. I am using Fedora for long time from the release of Fedora 23. I loved the community very much and I would love to become a part of this community which helps me improve and recognise my skill sets. I want to be with the community for a long time and explore all the corners of the Open Source.

Do you have any past involvement with the Fedora Project or another open-source project as a contributor?

Yes, I have contributed to Fedora Project. I have also contributed to another Open-source project named Coala. During Hacktoberfest, I have contributed to other Open Source projects too.

  • Fedora
    • I have been working with the Fedora Community for the past 3 months and have made contributions to the community through bug fixing and writing documents.
    • I have worked on some of the issues in Fedora-infra/bodhi which are related to python and HTML , CSS. These also include the documentation that I made.
    • I have also contributed to projectatomic/rpm-ostree through writing documentation in it.
  • Coala
    • Coala provides a unified command-line interface for linting and fixing all codes of users, regardless of the programming language user uses. I have fixed some bugs in coala.[1] [2].
  • Other open source contributions:
    • I have actively contributed to different Open Source projects during Hacktoberfest.[3] [4] [5]

Have you participated in GSoC in the past? If so, what year(s) and which organization(s)?

No, I haven’t participated GSoC in the past, this is my first time and I am excited to be a part of it.

Do you plan to continue contributing to the Fedora Project after GSoC? If yes, what sub-project(s) are you interested with?

Yes, I will continue contributing to Fedora Project after GSoC . The sub-projects that interests me are fedora-CommOps, fedora-infra/bodhi and projectatomic/rpm-ostree. I would also like to contribute to fedora-hubs.

Why should we choose you over other applicants?

I am currently in my 1st year of Bachelors in Computer Science and Engineering. I spend most of my time in FOSS Club (Free and Open Source Software ) at my University where we actively engage in contributing to Open Source. Since the time I got to know about Fedora I am contributing to it. I would like to learn more from the mentors and people of the fedora-community and build my skills. I consider GSoC as a wonderful learning opportunity and a perfect way to improve my skills.

  • Familiar with primary open source techniques( issue tracking, mailing list and version control system, IRC).
  • I was learning git when I started to contribute and now I am pretty good with it.
  • I have experience with Object Oriented programming and Web Technologies. I have ability to code in multiple languages including but not limited to C, C++, Python and I am also familiar with HTML, CSS, AngularJS.
  • I will contribute to the community by being more self sufficient (by using search engines, mailing list effectively and will ask right questions).

I take this program to be a great way to start with the Fedora-Community and dedicate my time to this community.

Which specific project interests you?

The project that interests me is the project related with Fedora CommOps. I want to work on this project as I have required set of skills and by working on this I would be able to learn more.

Have you contacted the mentor(s) listed for the project?

Yes, I contacted the mentors listed for the project and discussed the project and got guidelines how to get started with the project.

Project Description

Overview of the project

To build a central metrics generation system for Fedora with handy features to pull statistics. This collected data will be viewed on web interface for querying data.

Why to have this project (need)

Fedora has a neat service called datagrepper which allows querying the history of fedmsg bus. But, it is too slow for doing some more advanced reporting and analysis and which results in the inefficient metrics collection in CommOps( as it requires manual work). Scripts are written to collect data for events/FAS groups users which query datagrepper and returns results, which is time consuming, redundant and tedious process.

Goals

  • Custom statscache plugins for various metrics having ability to generate weekly/monthly/quarterly/yearly reports.
  • A web application to run queries (with a clear interface - based on statscache)
  • API for all the queries functions.
  • Automatic statistics generation and storage.
  • Well-Documented code.
  • Deploying it to the production (if possible).

Relevant experience

  • I am using Fedora for a long time since, the release of Fedora 23.
  • I have also worked on projects related with Python, HTML, CSS and JavaScript which are on my github.
  • I am familiar with the APIs.
  • I have worked with Fedora (in fedora-infra/bodhi) and I know how community works.
  • I am also contributing to documentation for fedora-infra/bodhi and I have experience in writing a good documentation for a project which is one of the most important thing for a project.

Implementation of proposal

As it is mentioned in the pagure ticket which is referred on the project idea, this can be achieved through statscache to build a central generation system for Fedora. Statscache consumes all the messages and does not query datagrepper every single time thereby increasing the efficiency. While building on top of statscache the number of scripts used to get the data can be significantly reduced to almost zero.

In this project, three types of plugins are required one for the statistics by FAS groups, one for the statistics based on badges and the last one for the statistics based on FAS trend. When a message arrives at statscache, a fedmsg consumer receives it and hands a copy to each loaded plugin for processing. Each plugin internally caches the result of this message for processing untill a polling producer instructs it to update its database model and empty its cache.. So, if we want a new kind of statistics to be kept, we need to write a new plugin for it. To get statscache to load and run plugins, include its class as an entry -point under statscache.plugin in the package’s setup.py.

Screenshot from 2017-04-02 23-33-33.png

Diagram explaining how the whole process will take place. From the creation of plug-in to integrating it with the web application.

To allow integration of statscache with other web applications and services, statscache’s easy-to-use REST API can be used which supports multiple data formats. We also need to revamp the statscache interface and interactivity to the interface. The web app will have some of the interactive features like filtering by date and it will generate graphs as per described by the user after filling some queries. It will be linked to the FAS account of the user to prevent unauthorized access. For badges statistics, it will ask the user to select the badge and will show the activity of the users in that time period specified. In case FAS trend user will be asked to enter the FAS ID of the newcomer (or can be anybody from fedora) and it will display all the recent activity related to that person between the time period specified. For FAS group statistics it will ask for the FAS group name and then it will display the statistics based on different categories (like number of members etc). We can use charting libraries of python to generate the charts for the statistics.

The system can provide visualization of data as a bar/line graph or pie chart for statistical reasons. After clicking the generate statistics button a pop can open which will ask the user to select the nature of the graph.

  • Ability to generate weekly/monthly/quarterly/yearly reports.
    • Ability to generate weekly/monthly/yearly reports will help in making the metrics more accurate and readable for user. And it will also help in making the date filter so, that bages and updates can be checked within a time period.
  • Well-documented code
  • A web interface for generating the statistics.
    • Web interface will allow the users to run query and get the results either in graphical form or in the statistical form to get the information.
  • Automatic statistics generation and storage.
    • This would help in exporting the the metrics so, that it can be used in different formats (CSV,, SVG etc).
  • Deploy the final deliverable on production.

Final deliverable

  • Custom statscache plugins for the FAS group metrics, Fedora badge metric sand FAS account trend metrics
  • Useful metrics and statistics which can be exported to different formats.
  • Web application which will allow the user to run query and generate the statistics ( in form of graphs ).
  • API for all queries functions
  • Well documented code for better understanding of other developers.

A rough timeline for your progress

Dates Details
Community bonding period [ May 4th - May 29th] (25 days)
  • Since I am familiar with the community as I was contributing from 3 months so, during this period I will also work on these too :
    • Work locally with statscache and explore it.
    • Figure out how statscache can be expanded to accommodate the new requirements.
    • Familiarize with the working of fedmsg.
    • Familiarize with the working of fedora-stats-tool.
    • Discuss more about the project from the mentors.
Official Coding begins
[ May 30th - June 12th ] (2 week) ( 8 hours per day)
  • Start working on with the high priority task i.e., to make custom statscache plugins . During this period of time, I will work on the plugin to get the statistics by FAS groups.
[ June 13th - June 26th ] (2 week) ( 8 hours per day)
  • During this period I will work on creating the second plugin i.e., plugin to get statistics by Fedora badges.
PHASE I EVALUATION
  • Plugin for FAS group and Fedora badges.
[ June 27th - July 9th] (2 weeks) ( 8 hours per day) During this period I will work on creating the third plugin i.e., plugin to get statistics by FAS Account trends.
[ July 10th - July 16th ] (1 weeks) (7 hours per day)
  • Work on additional plugins( if any).
[ July 17th - 28th July ] (2 weeks) (7 hours per day)
  • Revamping the statscache interface and adding interactivity to the interface.
PHASE II EVALUATION
  • Plugin for FAS account trend, additional plugin(if any) and interactive interface for statscache.
[ August 29th - August 5th] (1 week) ( 7 hours per day)
  • Deploying the centralised metrics system to the production.
[August 6th - August 21st] ( 2 weeks) ( 7 hours per day)
  • Pencils down time, debugging and writing the documentation.
After GSoC
  • I will continue contributing to the Fedora Project and would like to become a core contributor.

Prior commitments and Plans during the summer

I will be having my University end-semester exams during 15th May - 27th May, but I will try my best to not to have any communication delay.

References

Mentors

  • Sachin S Kamath (Skamath)
  • Bhagyashree (bee2502)