389-devel October 2019

389-devel@lists.fedoraproject.org

8 participants
48 discussions

Start a nNew thread

Please Review 50669 - remove nuncstans
by William Brown 22 Oct '19

22 Oct '19

https://pagure.io/389-ds-base/issue/50669 https://pagure.io/389-ds-base/pull-request/50670 -- Sincerely, William

1 0

389 DS nightly 2019-10-23 - 96% PASS
by vashirov＠redhat.com 22 Oct '19

22 Oct '19

https://fedorapeople.org/groups/389ds/ci/nightly/2019/10/23/report-389-ds-b…

1 0

Future of nunc-stans
by William Brown 22 Oct '19

22 Oct '19

Hi everyone, In our previous catch up (about 4/5 weeks ago when I was visiting Matus/Simon), we talked about nunc-stans and getting it at least cleaned up and into the code base. I've been looking at it again, and really thinking about it and reflecting on it and I have a lot of questions and ideas now. The main question is *why* do we want it merged? Is it performance? Recently I provided a patch that yielded an approximate ~30% speed up in the entire server through put just by changing our existing connection code. Is it features? What features are we wanting from this? We have no complaints about our current threading model and thread allocations. Is it maximum number of connections? We can always change the conntable to a better datastructure that would help scale this number higher (which would also yield a performance gain). The more I have looked at the code, I guess with time and experience, the more hesitant I am to actually commit to merging it. It was designed by people who did not understand low-level concurrency issues and memory architectures of systems, so it's had a huge number of (difficult and subtle) unsafety issues. And while most of those are fixed, what it does is duplicating the connection structure from core 389, leading to weird solutions like lock sharing and having to use monitors and more. We've tried a few times to push forward with this, but each time we end up with a lot of complexity and fragility. So I'm currently thinking a better idea is to step back, re-evaluate what the problem is we are trying to solve for, then to solve *that*. The question now is "what is the concern that ns would solve". From knowing that, then we can make a plan and approach it more constructively I think. At the end of the day, I'm questioning if we should just rm -r src/nunc-stans and rethink this whole approach - there are just too many architectural flaws and limitations in ns that are causing us headaches. Ideas and thoughts? -- Sincerely, William

6 10

Please review: 50667 dsctl -l to use paths.
by William Brown 22 Oct '19

22 Oct '19

https://pagure.io/389-ds-base/pull-request/50668 -- Sincerely, William

1 0

389 DS nightly 2019-10-21 - 96% PASS
by vashirov＠redhat.com 20 Oct '19

20 Oct '19

https://fedorapeople.org/groups/389ds/ci/nightly/2019/10/21/report-389-ds-b…

1 0

389 DS nightly 2019-10-20 - 96% PASS
by vashirov＠redhat.com 19 Oct '19

19 Oct '19

https://fedorapeople.org/groups/389ds/ci/nightly/2019/10/20/report-389-ds-b…

1 0

389 DS nightly 2019-10-19 - 96% PASS
by vashirov＠redhat.com 18 Oct '19

18 Oct '19

https://fedorapeople.org/groups/389ds/ci/nightly/2019/10/19/report-389-ds-b…

1 0

389 DS nightly 2019-10-18 - 94% PASS
by vashirov＠redhat.com 17 Oct '19

17 Oct '19

https://fedorapeople.org/groups/389ds/ci/nightly/2019/10/18/report-389-ds-b…

1 0

389 DS nightly 2019-10-17 - 96% PASS
by vashirov＠redhat.com 16 Oct '19

16 Oct '19

https://fedorapeople.org/groups/389ds/ci/nightly/2019/10/17/report-389-ds-b…

1 0

please review: PR 50656 - access log etime is not properly formatted
by Mark Reynolds 16 Oct '19

16 Oct '19

https://pagure.io/389-ds-base/pull-request/50656 -- 389 Directory Server Development Team

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel October 2019