> > Hi, > > For my part, I have seen mapping tree misconfiguration popping from time to > time but it is quite rare (maybe 7 or 8 times in 15 years) > So although in pure term or architecture your proposal is IMHO the cleanest, > in term of risks it is not a good solution: > there will likely be regressions (it always happens when a component get > redesigned) > and that means that the number of people that will be annoyed by the change > will be far greater than the few people that will be helped by the change.
Today, we already rely upon the attribute of cn to determine what suffix the mapping tree element provides. We must trust this value, and already do. This also implies that all current deployments, also trust this value to be correct. It is also provable by tests that *invalid* nsslapd-parent-suffix configs cause backends to "not appear" in the mapping tree. So invalid parent suffixes already fail "noisly". This means, yes, that most deployments have both valid cn's for suffixes and valid nsslapd-parent-suffix values. While it may be rare, we have had a few cases here at suse because the lib389 tools make a mistake in configuration that can easily and trivially cause this failure. So changing this to trust a value of cn to provide ordering, this is already a value we rely on to be correct *and* we remove an obvious configuration consistency failure that has occurred. It is because of these factors that I am more confident that we can make this change with low risk. > > So my feeling is that we should rather go for a trade off. > Since the goal is to prevent that user misconfigures the mapping tree > without warning, > we should do that without changing the way the mapping tree is handled > internally. > simply by adding a consistency check when starting the server or changing > the mapping tree configuration. > > If we want to limit the risk we could phase things: > in first phase we only log warning if inconsistency are found > and latter on when we get more confident about the code we could reject the > configuration change in case of inconsistency > > I know that my proposal is less appealing in term of architecture but such a > solution is safer because it does not change the way mapping tree are handled > and that drastically limits the regression risks Generally it's my view that we should always prioritise constraint and "inability to make mistakes" over "warning about mistakes". There is certainly value in providing warnings about mistakes when they occur, but preventing the mistake from ever occuring is a far more reliable option. Our server should ensure that there is "no way to hold it incorrectly". In the situation where we "warn", that would then actually mean we have to redesign some parts of lib389 to parse and generate a mapping tree itself so it can then correctly determine the parent-suffixs to emit into configs when it attaches a backend into the tree. This would also itself be a significant chunk of work, and a risk of breaking our cli tools too, while also "not preventing" the issue for any other administration methods that exist. I think that your suggestion is moving the burden of correctness from our work in the server as engineers, onto administrators and our tooling to "understand and use it correctly", and that doesn't really sit right with me. So I'd rather continue with the suggestion I have made as we eliminate an entire class of potential problems. In order to really see understand the percieved risks of this change, I'd really like to see configurations that would cause this proposal to fail, and then those can become tests that we can understand and resolve issues with. Thanks, — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia _______________________________________________ 389-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
