GSOC 2017/Student Application ankity10

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.

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.

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/.

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).

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.

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.

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.

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
June 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	-

Contents