From Fedora Project Wiki
Contact Information:
- Name: Ankit Yadav
- Time Zone: UTC + 5:30
- Email: ankitwrk AT gmail DOT com
- IRC Nick: ankity10, ankity10_
- Mob: +91 8087850104
- 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.