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