[389-devel] Please review (tests) 47628: port test cases to new DirSrv interface

[thierry bordaz]

Hello Roberto,

    Thanks, I also wish you an happy new year and you recover well. It
    is great to talk to you again :-) .

    I am quite novice with python and my first approach was to use it as
    a real object oriented language, having instances of everything
    (suffix, MT, replica, indexes...). Then discussing with Jan and
    looking at your implementation of dsadmin, I realized that it is a
    common use to wrap methods of class and rather use python as a
    functional language (e.g. self.backend.setProperties(...) rather
    than 'backend=Backend(); backend.setProperties(..) ')
    The big advantage I see in functional approach is that the 'object'
    are no long python objects but the configuration object stored in
    'cn=config'. So it prevents the problem of synchronizing the python
    object with the 'cn=config' object. So the only remaining object is
    the DS instance (dirsrv/dsadmin) and methods to access its config.

    Does it prevent to use fake directory ? I am not enough familiar
    with fakeldap, would you give me an example of why the current
    implement would not work with fakeldap ?

    About the shift of parameters to dictionary I think both approaches
    are valid. Just let me explain why I choose dictionary, it comes
    from what could be future CLI.
    for example we may have a CLI pattern like:

    <admin_cmd> <verb-resource> [parameters] [options]

    admin_cmd::= "dsadmin"
    verb-resource::= <verb-suffix> | <verb-replication> | <verb-backend>
    |...
    <verb-suffix> ::= list-suffix | create-suffix | delete-suffix...
    parameter::= <parameters to connect to the DS instance (port,
    credential..)>
    options::= <option to process the command and also some properties>

    Then we have specific <verb-resource> to define the resource
    properties (entry cache size, directory path, type of replica...)

    They are set-suffix-prop, set-backend-prop...
    Basically once the resource has been created (with some properties),
    any 'properties' of the resource can be read/write by
    set/get-<resource>-prop.

    So for the CLI (or other admin application) we need to send
    prop:value to an instance. prop are then available in an include
    file, but in a human-readable way (like 'suffix') rather than in an
    attribute way (like 'nsds5replicaroot'). I used a dictionary to pass
    the properties (rather than functions arguments) mainly because some
    resource may have many properties, also because all the
    set-<resource>-prop function have a similar interface.

    I do not know if I answer correctly your concerns. Just let me know
    if I missed your questions.

    regards
    thierry

On 01/03/2014 01:10 PM, Roberto Polli wrote:
> Hi Everybody!
>
> First of all Happy New Year, hope it will be filled of fun!
>
> I am really sorry for not supporting you for so long, but as I told you I
> can't still spend too much extra-work time coding :(.
>
> I saw the evolution of the library and I'm glad of the new functionalities and
> the split-up of the brooker in various files.
>
> On the other hand I think that the new interface changes don't go on the
> simplicity/usability path, so I'd like to understand your targets and give
> some suggestions.
>
> On Thursday 12 December 2013 21:58:12 thierry bordaz wrote:
>> Ticket https://fedorahosted.org/389/ticket/47625 changes the interface
>> of DirSrv.
>> This ticket is the porting side of the test cases to the new interface
> 1- The new interface initialization is substantially different from a standard
> client-server interface. A user expects to instantiate objects like this:
>   # client =  Telnet(host, port, credential)
>
> 2- This is quite the behavior of the LDAPObject superclass, which I would like
> to retain so that we can use fakeldaps for unittest
>
> 3-  The standard DirSrv.__init__ (and the same is valid for other methods),
> containing a set of parameters is intrinsically documented. Shifting core
> parameters in dictionaries:
>   a- de-documents parameters and default values outside the method signature;
>   b- requires parsing and setting of default values;
>   Python allows to retain the dict-style stuff using the **magic, which I would
> embrace in this case.
>
> The new Interface Layer would be easily implemented in a subclass.
>
> Let me know + Peace (and sorry again for my absence),
> R.
>
>> https://fedorahosted.org/389/attachment/ticket/47628/0001-Ticket-47628-port-> testcases-to-new-DirSrv-interface.patch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-devel/attachments/20140103/b8f7b118/attachment.html>