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) Regards Pierre On Fri, Oct 16, 2020 at 1:35 AM William Brown <[email protected]> wrote: > > > > > 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] >
_______________________________________________ 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]
