Personal Details
- Name: Abhishek Kumar Singh
- Freenode IRC Nick: kanha
- Mobile No: +91 8893839740
- Time Zone: IST(GMT + 5:30)
- Blog URL: abhisheksingh01.wordpress.com
- Email Address: abhishekkumarsingh.cse@gmail.com
Why do you want to work with the Fedora Project?
I am passionate about OSS(Open Source Software). During the initial phase of my contribution to SSSD I got a chance to play with Fedora 18 and I was impressed by it to such an extent that I am a Fedora user now. Fedora is really cool and an awesome OS with everything being so lucid, attractive and the last but not the least an impressive GUI. It will be give me immense pleasure contributing to the product which I admire most.
Do you have any past involvement with the Fedora project or any other open source project as a contributor?
I have contributed to other open source project as well https://fedoraproject.org/wiki/User:Abhisheksingh/contributions .
Did you participate with the past GSoC programs, if so which years, which organizations?
No
Will you continue contributing/ supporting the Fedora project after the GSoC 2013 program, if yes, which team(s), you are interested with?
Yes, I will continue my support,contributions to Fedora project even after Gsoc 2013. I am interested in SSSD team and QA team.There are lots of opportunities for contribution with the release of SSSD 1.9.5 and focus on developing new features for upcoming SSSD 1.10.
Why should we choose you over other applicants?
I have sound programming skills in C, C++ and Python. I have acquired good knowledge of cmocka framework and have done some initial contribution in support of my proposal. I am willing to contribute and support my project through out my lifetime, also I have keen interest in contributing to SSSD and QA community after GSoC 2013.
Implement a battery of unit tests for SSSD
Introduction
An idea of implementing a battery of unit tests for SSSD(System Service Security Daemon) using cmocka unit test framework is proposed after having a good discussion with jhrozek(Jakub Hrozek, #sssd). Actually, it is not just writing better automated test codes but a total refinement of SSSD unit-tests including cmocka unit testing framework in such a way that it will reduce complexity of code make it efficient and provide a good mocking framework for better testing. Following are the details of the project and the proposed plan of action.
Abstract
Implementing unit tests for SSSD modules using cmocka unit testing framework with proper refactoring, minimum boilerplates and better test coverage. Doing sanity checking, resulting in efficient test codes.
Benefits to Fedora community
- Contributing the set of unit tests to the SSSD would greatly improve its stability long-term and would help raise confidence when pushing new SSSD versions into Fedora or other distributions.
- Making SSSD tests less complicated and mocking based Unittesting framework would certainly result into an improved testing mechanism and error handling in SSSD.
- Improvement in the test coverage will result in improvement of code quality of mozbase.
- Writing unit-test will help in deep extensibilty to the behaviour of SSSD code and eventually results in solving many of the issuses related to SSSD-testing on bug tracker
Project Details
The aim of the project is not just quality assurance of SSSD but to provide a proper implementation of a Unit testing framework rather than just a POC(proof of concept). It has far greater goals. SSSD is so important that all of Linux based operating systems uses it including Fedora and others. But the Current version of SSSD lacks proper unit testing framework for exercising the code which are only reachable when SSSD is connected to the network. This project deals more about writing new efficient cmocka based tests and complete refinement of old written SSSD tests using cmocka framework. The idea here is to dig deeper into testing to provide and maintain long-term robustness and quality of SSSD. It is also important that the new cmocka based tests should be less complex and more efficient. It should have more automated behavior and minimum or no boilerplate. It should also follow proper coding styles followed by SSSD.
One other feature of the framework should be that it should be sustainable and support further improvements. It means that if the tests need to be implemented further because of addition or enhancement of new feature(s) or tests need to be modified after a year or something, only slight change in the fixers should be enough and an automated process would be taking care of implementation of respective fixers to the tests. Since, it would be quite troublesome to implement all the tests again and again with each new modification or new release of SSSD dependencies, this feature is quite necessary from development perspective.
Tools Required During Development
- Talloc and Tevent
- Cmocka library
- Coverage tool : lcov
- Vim (IDE)
The outline of my work plans
The initial stage of my work deals with becoming familiar with SSSD and learning concepts of cmocka unit-testing framework as mentioned in plan.
The general idea for the unit tests is to cover the two most important parts:
- getting user information
- authenticating users.
So, basically the whole project is divided into two phases:
- Phase I : building provider tests
- Phase II: building responder tests
The unit tests would cover the NSS and PAM responders. The back end tests would cover the LDAP users and group code. These are the most important parts of the SSSD thus focus will be mainly on providing good tests for them.
Time-line for Milestones
Week 1 - Learning the tevent library and the async model
Week 2 - Learning the tevent library and the async model. Might include
some experimenting and reading the code of the
Week 3 - Reading the current NSS responder test and augmenting the "get
user by XXX tests"
Week 4 - Add a similar test for retrieving groups as added for users in
the previous step
Week 5 - Add another test for the initgroups operation
Week 6 - Study the PAM responder code.
Week 7 - Add a unit test that would cover the PAM responder. Only login
(auth phase) can be covered.
Week 8 - Learning the backend and provider internals. The current DNS
update tests might be a good start.
Week 9 - Create unit tests for retrieving LDAP users. These tests would
not be big by themselves, but would include code to be reused by
other LDAP tests later
Week 10 - Create unit tests for storing LDAP groups without nesting
(RFC2307)
Week 11 - Create unit tests for storing LDAP groups with nesting
(RFC2307bis)
Week 12 - An extra week to polish the work before submission
Have you communicated with a potential mentor? If so, who?
Yes, I am in touch with Jakub Hrozek(jhrozek, #sssd) for quite long time.