On 19.10.20 01:26, William Brown wrote:
On 16 Oct 2020, at 17:48, Pierre Rogier wrote:
Hi William,
I agree with your architecture points and that is why I said my proposal is a
less appealing trade off.
My real concern is your last point:
we just do not know and IMHO we are unable to predict what (or if) config
will cause problems, and I am afraid we will only discover it when people start
to complain.
So I still think that the benefit/risk ratio is bad)
I think this wasn't my point. The thing is *any* change will have that "unknown" risk.
Our job is to qualify and identify as many of those risks as we can, to remove them as unknowns.
Think about the work recently to merge the changelog to the main db, or BDB to LMDB work, even
changing from perl to python for installation. These are all significantly larger changes, which
would be "much riskier" but all of them have been managed effectively by the team
communicating, coordinating, analysing, designing and testing changes.
So I really don't accept this "unknown" risk argument. I have laid out a design
that explores the configuration, how it works today and how the values are currently
trusted, and a process to manage and understand this change in a way to minimise the
risk. There are associated tests, and it passes with address sanitiser, and other test
cases for mapping trees, replication and others.
If we just say "unknown risk" at every change we make we'd never progress. We
may as well packup and go home, the project is completed.
if you put it that way any change is justified because it is a change.
Changes are necessary to achieve something, eg features performance (and
I would distinguish changes from fixes).
This started, as you said yourself, because:
>>>
This has come up because there is a set of customer cases where they have
configured it incorrectly, due to bugs in lib389. The issues in lib389 arise
from a lack of validation/constraint in the checking of the
nsslapd-parent-suffix value in the server, allowing the client to create
invalid configurations.
So today, our own tools can easily, and trivially cause this situation.
<<<
So we have situation where the design has flaws, but in effect was
"working" and the we messed up ourselves by providing tools which can
easily break things. And here I would say it is justified to discuss the
balance of fixing the tools and eventually adding some checks to the
server vs reimplementing it with the risk that the design,
implementation and new tooling will als have challenges.
Ludwig
So I still stand by my design and the PR I have submitted in this case, and if
there are concerns about esoteric configurations, then we should identify and
understand them too beyond the testing I have already provided.
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
