GSOC 2017/Student Application ankity10

Contact Information:

---

• Name: Ankit Yadav
• Time Zone: UTC + 5:30
• Email: ankitwrk AT gmail DOT com
• IRC Nick: ankity10, ankity10_
• Mob: +91 8087850104, +91 8668644837
• Mentor: William Brown (firstyear)

Abstract:

---

• Administration of 389-ds-server is a complex task. Currently there are some perl scripts that are installed with 389-ds-server instance which administer specific parts of server. But the server cannot be managed from these perl scripts alone. To simplify this complex Directory Server management, new tools are being developed.
• lib389 is a python library that uses LDAP to communicate with 389-ds-server. This library exposes its functionality with the help of two command line tools dsconf and dsctl (earlier it was “dsadm”, renamed due to naming conflict with “dsidm” ). In lib389 most of the base classes that communicate with 389-ds-server are already written.
• This project aims to add new modules in lib389 to replace the legacy tools (perl scripts, java console application) and extend command line python tool “dsconf” to support its enabling / disabling / configuration.

Benefits to Community:

---

• Successful completion of this project will help administrators to manage 389-ds-server in effortless way and “dsconf” will be the one stop solution for all the configuration related tasks.

Tasks:

---

• Add two new modules to extend the command line tool “dsconf” that will inherit the core base classes DSLdapObjects and DSLdapObject which are in file lib389/_mapped_object.py.
• Write pytest tests for the above modules.
• Adding new command line module for two newly added modules in lib389/cli_conf/ so that “dsconf” can be used to call module specific functionality.
• Write pytest tests for above command line modules in folder lib389/tests/cli/.

Implementation Details:

---

1. Adding new modules in lib389:

• DSLdapObject is a python class abstract of Relative Distinguished Names (RDN). Each RDN in a DN corresponds to a branch in the directory Information tree (DIT).
• DSLdapObjects is a python class abstract of Distinguished Names (DN). A DN is a unique name that unambiguously identifies a single entry.
• DSLdapObjects and DSLdapObject also implement the core logic to interact with Directory Server via LDAP protocol using python2 ldap client library.
• New modules will inherit from the classes DSLdapObjects and DSLdapObject so that they can interact with Directory Server by calling functions of class DSLdapObjects and DSLdapObject from file lib389/_mapped_object.py (LDAP ORM).
• These new module’s functionality will replace some of the legacy tools (Perl scripts and Shell scripts).

2. Write test for modules in folder lib389/tests/:

• lib389 tests uses pytest tests, pytest is a python module to write easy and scalable tests.
• pytest has some features like detailed info on failing native python assert statements, auto-discovery of tests and modular fixtures for parameterized test resources.
• To write pytest tests for new modules in lib389, we can define a module scope fixture "topology".
• This "topology" fixture will create the Directory Server instances required for running the tests. Fixture “topology” will be passed as an argument to each test case.
• Since we are using pytest tests we can use native python assert statements to confirm the test output with expected output.

3. Adding a new command line module using previous module in lib389/cli_conf/:

• In this module we will have to create a parser for command line arguments.
• This module will make use of generic and reusable functions defined in file lib389/cli_base/__init__.py. These functions are defined with a motive to reuse the code.
• These generic functions will accept one of its arguments as manager class (manager class can be backend class, plugin class or new modules ).
• Manager class is a module selected by user while using “dsconf”. In our case it will be 1 of 2 modules that needs to be added.
• These generic functions call the manager class for module specific functionality.

4. Write tests for command line module::

• Since in lib389 we are using pytest to run our test modules, native python assert statements can be used.
• Command line modules can be tested by intercepting the logs and making assertions of search query of keywords in intercepted logs.
• LogCapture class is for intercepting the logs.
• To test the command line module, we will use the class LogCapture from file lib389/cli_base/__init__.py
• We will make assertions of search query of keywords in logs.

Timeline:

---

Date	Tasks	Deliverable
May 4 - May 16	Understand the codebase and ask questions to clarify concepts.	-
May 17 - May 31	Discussion with mentor about which modules to be developed as a part of gsoc.	-
June 1 - June 10	Write code for module 1 to extend “dsconf” functionality	Module 1
June 11 - June 15	Write tests for module 1.	Module 1 Unit Tests
June 16 - June 20	Write command line module for module 1	Command line module 1
June 21 - May 25	Write tests for command line module 1	Command line module 1 Unit Tests
June 26	Write docs for module 1	Docs for module 1
June 27 - June 29	Buffer time to deal with any unplanned interrupts in schedule.	Complete module 1
June 30	Phase 1 Evaluation deadline	-
July 1 - July 10	Write code for module 2	Module 2
July 11 - July 15	Write tests for module 2	Module 2 Unit Tests
July 16 - July 20	Write command line module for module 2	Command line module 2
July 21 - July 25	Write tests for command line module 2	Command line module 2 Unit Tests
July 26	Write docs for module 2	Docs for module 2
July 27 - July 28	Buffer time to deal with any interrupts in schedule.	Complete module 2
July 28	Phase 2 Evaluation deadline	-
July 29 - Aug 11	Addition of final hooks in “dsconf”	“dsconf” wired with Module 1 and Module 2
Aug 12 - Aug 20	Write report on experience and documentation updates if any.	Updated Documentation and experience report
Aug 21 - Aug 29	Final submission Week	-

About Me:

---

• I am a senior year Computer Engineering student from Pune Institute of Computer Technology, Pune, India. I’ve had an interest in Computer Science since high school where I learnt about the C++ language. This, eventually, motivated me to pursue a career in Computer Engineering.

• My primary drives are curiosity and learning about new things. I always try to keep myself updated with new technologies and try to apply my skills in any project that I work upon. During my sophomore year, I became interested in web technologies and started diving deep into it. This led to siteflu.com, a venture I started with 3 of my friends. Siteflu was built to provide web consultancy to clients by helping them build their websites with a clean functional UX.

• I am proficient in Python when it comes to working with applications and web technologies. I’m an active member of the local Python meetups and have been participating in PyConf since the past two years.

• While working on a project, I mentally typecast the project into a design puzzle. This always keeps me interested in every single part of the project. Right from meticulously planning out the architecture to programming it, testing it for bugs and ensuring that user experience (UX) is always pleasant. I try to use object oriented approach wherever possible. It keeps the code clean, helps me to divide the work into modular chunks and helps me to plan out how to unit test each module. I believe that UX is integral to any software, even if it is a backend command line utility. Siteflu.com has been integral in helping me get a good sense of design and UX.

Relevant Experience:

---

• Majority of my experience stems from the projects that I worked upon. Following are some of the major projects that have helped me gain relevant experience:

1. Siteflu.com

• I worked at Siteflu.com for a year and in the process, gained valuable experience in working with Python, Django, JavaScript and NodeJS. I also learned the importance of design and UX while working on multiple client projects.
• Link: Siteflu.com

2. Notelet: Contextual Notes in Linux

• I, along with 3 of my friends, worked on Notelet under the guidance of a remote mentor located in California, USA.

Here’s an overview of Notelet:

• Notelet desktop application: In Notelet, the context is active windows, so a user can attach note for any active window context and read it when he comes back to that window.
• Notelet server: It enables a user to synchronise his/her notes across multiple machines.
• Technologies used: Python, PyQt, Node JS, JavaScript, RabbitMQ, Redis, MongoDb
• Here’s a link to the presentation of Notelet: Presentation
• We have plans to make this application open source very soon.
• Link: This can be provided upon request. Currently, it is a private repo.

3. MCQ Webapp

• MCQ web application is a python django application which allows a moderator to take MCQ tests of contestants (users).
• Link: MCQ-Web-App

4. Library Authentication API

• A Node JS API to provide endpoints for user login/signup using JWT auth and CRUD operations of library books by authenticated users.
• Link: Library Authentication API

5. File Deduplicator

• A python script to find duplicate files and delete them after user confirmation.
• Link:File Deduplicator

6. TextFS

• A File System implemented with python to store text information in scrambled form in a single text file.
• Link: TextFS

Open Source Contributions:

---

• I decided to work on one issue #1 of lib389 but could not complete it because I failed to setup lib389. I was unable to setup lib389 in my fedora 25 because of one bug (issue #49179) in 389-ds-base v-1.3.5 that I found while I was setting up lib389.
• So I ended up raising a bug (issue #49179) in 389-ds-base repository instead of solving an issue of lib389. It was a great learning experience and I learned about writing tests for lib389 using pytest.
• The bug has been resolved and I have successfully setup the lib389 repository and 389-ds-server. I will continue to work on that lib389 issue #1 after April 3 2017.

Why Me?

---

• I have always been passionate about open source software. Up until now, I have only been using it and now I have a chance to contribute to a major piece of software! This has always been one of my dreams. Along with this, I’ve always wanted to work with a large codebase ever since I read The Practice of Programming and The Pragmatic Programmer. The icing on the cake is working with a geographically distributed team.

• My year long experience with siteflu has developed an intuition towards user experience in software which will be useful in designing “dsconf” command line APIs. During the course of my senior year project, I have worked remotely with a remote mentor from California, United States. This exhibits my ability of working with someone from different country and timezone. I have used pytest for automated testing of the server in our senior year project which will help in working on this project. I am also accustomed to git version control system, having used it extensively while developing Notelet.

• I have already setup lib389 and have already partially acquainted myself with the codebase and LDAP. This will eliminate the ramp up process and allow me to immediately dive into the project.

• I believe that under the guidance of the lib389 mentors, I can effectively apply my skills to work on this project. Once complete, I would love to become the maintainer of these tools. This will be an immense learning experience for me and I’ll make sure that it will be a very high quality contribution to this project since I have always believed in the idea of giving back to the community.

Why Fedora?

---

• Fedora is to RHEL what Debian Sid is to Debian Stable. RHEL is the most stable distribution in existence and every good feature that becomes stable on Fedora eventually makes it to RHEL. Hence, contribution to Fedora → contribution to RHEL→ contribution to the most stable OS which runs some of the most critical software in the world! This gives me an exhilarating feeling! I have been using Linux since 2011. I switched to Fedora after attending my first PyConf in 2016. In PyConf, India - 2016, speakers from Red Hat gave us insights about Fedora community. I immediately fell in love with Fedora and haven’t looked back.

• Four core values of Fedora community are Freedom, Friends, Features, First and my thinking towards Open Source community is aligned to them. By providing free alternatives to proprietary softwares, Fedora is enhancing the Open Source world and I want to be part of such community.

• I want to continue contributing to Fedora Project even after GSoC. I will continue to work on administrative tools for 389-ds-base - lib389. Apart from this project, I am also interested in Ansible and Anaconda.

Why This Project?

---

• In this GSoC, I found this project very interesting. It has a clean and modular codebase. I will learn about engineering principles and the review process that needs to be followed with a geographically distributed team on a project with high quality demand which is why I want to spend this summer working on lib389. Working on this project’s large codebase will surely improve my development skills especially writing clean and reusable code. I always wanted to work on a project with a very modular design in python and lib389 fits the best in my interest.

• I have contacted Mr. William Brown, mentor of this project. We’ve had discussions on IRC channel #389, mailing list as well as on lib389 - pagure issue tracker while I was setting up the lib389. I have also started working on a issue #1 with the help of the mentor.

Other Commitments:

---

• My university exams are scheduled from May 16th - May 24th. Except this period, I will be available throughout the summer to work on the GSoC project.