Skip to main content

Week 1 :- CERN-HSF @ GSoC 2018

This week was the official start of the coding period for GSoC 2018 from 14th May onwards. Tasks were completed as per the proposed schedule in the application. A small summary of the work done is mentioned below along with other activities done during the week.

This week was also special as I participated in the bi-weekly meeting of DIRAC Developers team as a member and interacted with other developers of the group and laid the foundations of the project with various inputs received from them.

Tasks completed within this week:
  • Completed the testing of Job Monitoring and Job State services with fixing installation problems with respect to modules available.
  • Created Pull Request (link) on GitHub correcting documentation for certificates used for stating user and host devices.
  • Existing tests including unit and integration tests to verify the currently working modules are functioning properly.
  • Setting up ElasticSearch and verifying existing code to create indexes and types for the JobDB, as per the MySQL specifications.
Next week, majorly the work revolves around creating a wrapper to use ElasticSearch functions and accessing the data stored in the same.

List of tasks for every week can be found on the Trello task manager with the link present in the sidebar. 

Comments

Popular posts from this blog

My GSoC experience with CERN-HSF, Summer 2018

The Google Summer of Code (GSoC) program is one of the most prestigious programs for student developers, who are eager to work and demonstrate their skills in a full-fledged working environment. The program gives this opportunity to students all around the world and I feel good that I was selected for this program with the CERN-HSF organization, one of the pioneer organizations for nuclear research. My experience started before the GSoC program, with the first contact with the current mentor, Federico Stagni where we discussed the proposed project and my suitability for it by performing some tasks that are available here . Based on performance and my timelines, I submitted my proposal which went through multiple revisions with inputs from my mentor Federico and self-improvements. Finally, almost after a month of wait, students selected for GSoC 2018's program were announced and found myself fortunate to be selected with the following project with CERN-HSF:-  Monitoring and...

Week 9 :- CERN-HSF @ GSoC 2018

This week I was involved with working on Pull Request 3744  where some changes were demanded by other members of the organization as per the requirements of other components of the project. Firstly, as we moved towards adding a Jobs Status table (discussed in another post of the blog), which has eased and increased efficiency for query processing, we need to take care of the modules that accessed that table during any of there functions. Hence, it became important to analyze and test every module available in the Workload Management System as well as other modules that are accessing the table. A string of commits can be found below for the work done during this week: 0b1a63594eec932c12669d3274d5da705d9e2ffb fdda6f1fa473f866f0b552b838761f1201bc3c5b All the commits related to this issue can be found in this Pull Request .

Week 5 :- CERN-HSF @ GSoC 2018

This week I was involved with documentation and testing of the two DB backends: MySQL and ElasticSearch. Documentation: Added developer documentation for using the ES backend for Job Monitoring and Job Status Update. Includes all the functions of ES and in general full documentation of the Workload Management System (not present before in developer documentation). Performance Tests: It is very important that we are at least able to achieve similar performance while using ES backend when compared to MySQL DB. It should also be remembered that the main objective of moving to ES backend is efficient data management as currently, MySQL doesn't store all the incoming data and query processing also becomes difficult in that case. After implementing and using both backends individually, I tested both the DBs performance using multi-mechanize ( link ), a tool which helps in running concurrent process on a specified number of threads. Some of the results can be found here for ...