389-devel August 2017

389-devel@lists.fedoraproject.org

10 participants
52 discussions

Start a nNew thread

please review: Ticket 49038 - Remove legacy replication
by Mark Reynolds 04 Oct '17

04 Oct '17

https://pagure.io/389-ds-base/issue/49038 https://pagure.io/389-ds-base/issue/raw/fd4fec903b65d4a7cb32861012f24f5be76…

2 3

please review: Ticket 49370 - local password policies should use same defaults as the global policy
by Mark Reynolds 31 Aug '17

31 Aug '17

https://pagure.io/389-ds-base/issue/49370 https://pagure.io/389-ds-base/issue/raw/files/0df9672144d4292371ad05d722e9f…

1 0

Please review: Issue 48989 - Improve test execution time
by Viktor Ashirov 31 Aug '17

31 Aug '17

https://pagure.io/389-ds-base/issue/48989 https://pagure.io/389-ds-base/issue/raw/files/2540553868d83f47f6bdca4fa4e5a…

1 0

please review: Ticket 49038 - Fix regression caused by legacy replication code cleanup
by Mark Reynolds 29 Aug '17

29 Aug '17

https://pagure.io/389-ds-base/issue/49038 https://pagure.io/389-ds-base/issue/raw/files/e95b7815ec6de03ea3dbec6bdad8b…

1 1

Please review: Issue #77 - Add sphinx documentation
by Simon Pichugin 28 Aug '17

28 Aug '17

Hi team, Most of the comments were applied. Thanks! Now the layout is: - index.rst - welcoming word, Table of Contents and Contact Us. - guidelines.rst - is included into index.rst and contains basic test development workflow, pytest features overview, and basic lib389 and python-ldap features. - replica.rst, agreement.rst, aci.rst, etc. - each contains the respective documentation. Currently I do add docstrings to lib389 and rst files with references. It will be the next patch. Now, please, check if you agree with the existing format. The generated example - https://fedorapeople.org/~spichugi/html/ https://pagure.io/lib389/issue/raw/files/95c83274b06e9b48993af02040a23194f0… https://pagure.io/lib389/issue/77 Thanks, Simon

1 0

Please review: incorrect header definition.
by William Brown 27 Aug '17

27 Aug '17

https://pagure.io/389-ds-base/issue/49364 https://pagure.io/389-ds-base/issue/raw/files/8506b6c2724c4d9011dc610d02f18… -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane

1 0

Regression: TLS authentication from gcc fix
by William Brown 24 Aug '17

24 Aug '17

https://pagure.io/389-ds-base/issue/49275 https://pagure.io/389-ds-base/issue/raw/files/ebf93317162cb674d823836322e63… -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane

1 0

Please review: Issue 48059 - Add-docstrings-to-CLU-tests.patch
by Amita Sharma 24 Aug '17

24 Aug '17

https://pagure.io/389-ds-base/issue/48059 https://pagure.io/389-ds-base/issue/raw/files/28a4aed05a6a3894fdc88500e3658…

1 0

Please review: Issue 47840-Add docstrings to setup and use generate_ds_params
by Amita Sharma 23 Aug '17

23 Aug '17

https://pagure.io/389-ds-base/issue/47840 https://pagure.io/389-ds-base/issue/raw/files/eaa6e56273ea3713584e252043017… Thanks, Amita

1 0

future of lib389 - seperate or merged?
by William Brown 22 Aug '17

22 Aug '17

Hi all, Last night on IRC we were discussing the curious case of lib389. I think this is a discussion we should have at some point. The question really boils down to - "is lib389 a seperate project? Or is it part of 389-ds-base?" There are some pros and cons to both view points. lib389 is a python library that exposes high level interactions with 389 directory server. This is done by making various calls via LDAP to the server. The issue is that we have a split: we have tests in 389-ds-base/dirsrvtests that are often *version* dependent. They relate to features of the server, or issues in specific versions of the server that may not exist in older versions. Today we kind of stradle the line of "it's a bit of both". We have tests in 389-ds-base that depend on versions of lib389 - but lib389 moves quickly and has little ability to distinguish 389-ds-base versions. -- Merging lib389 to 389-ds-base One proposal is to merge them. We would mix in lib389 and the dirsrvtests into lib389 tests. It is often the case that lib389's features are bound tightly to a version of directory server. Pros: * No need to separate version lib389 to ds. lib389 is guaranteed to work with *that* version of DS * Testing DS is guaranteed to work. Right now we have rapid change in lib389 and the tests in say 1.3.5 or 1.2.11.x are unlikely to work with latest lib389. * We can tightly tie in features of DS with lib389 and their administration (ie no need to worry about backward compatibility). * Simpler release process - we only need to release 389-ds-base, and we are done. * No more split patches for lib389 features and tests. Cons: * We will need to backport lib389 features to backport tests for fixes to older versions. * Inability for latest lib389 to manage older (or newer) versions of ds. -- Separate lib389 We have lib389 as a project that moves at a different rate to the 389-ds-base project. Pros: * lib389 is able to use it's "knowledge" to administer *multiple* versions of Directory Server, rather that singly linked ones. * We can write tests into lib389 once and test them against all DS versions, or just relevant versions. * We can have the admin tools manage many versions of the software which may be cross platform/distro. * No more split patches for lib389 features and tests. Cons: * Need to invest time into version detection of the 389-ds-base package for configuration (both local and remote). IE we add a plugin in 1.3.7, but we need to know if lib389 is accessing 1.3.6 (and disallow the change). * Continue to manage separate release of software. * Need to manage lib389's older versions operating against *newer* 389-ds-base versions. This adds a lot of complexity and version checks (potentially with some server awareness?) -- Do nothing This is the current status. Pros: * We don't spend any time on the issue at all. Cons: * We get the worst of both worlds. * Continue to increase complexity as these diverge. * we often see the need to expand lib389 to express a test in 389-ds-base, so we will continue to need to split patches ============================ My vote is to merge them. I came to this decision because I believe that this will make development against multiple branches easier with regard to testing and backport of patches. For example, we'll know that lib389 that's inside of 1.3.7 will *always* work with that release, even if we have improved in 1.4.x etc. We also are developing new CLI and admin tools, and these are often tightly linked to a version of Directory Server. I think that it's easier for us as developers to have this specific linking, than trying to spend large amounts of time making something generic that works for all versions. For example, this would make the CI workflow much simpler as we just get "389-ds-base" and it's a self contained test suite and admin system. No need to get the "matching pairs" as the separate workflow would require. Thanks, I look forward to the discussion and various inputs to the this topic. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel August 2017