[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS review 9/29/2017

--On Friday, October 06, 2017 10:16 PM +0100 Howard Chu <hyc@symas.com> wrote:

its7442 - Add debug statements when index_intlen values are out of
range <https://github.com/quanah/openldap-scratch/tree/its7442>

Looks pointless.

Well, the man page is not clear on this point.  I'm fine dropping the
debug  statements, but what about the manpage updates which clarify the
min/max  allowed values?

Then we should also document all the other places where for example our
integers accept a max value of 4294967295 or 18446744073709551615 too?
It's stupid. Nobody is using 256 byte integers. Nobody is using integers
bigger than 256 bytes. (Come on, 2^2048? really?) It's a limit that no
one will ever hit in practice.

Well, I can certainly see why someone might expect they could set the minimum lower than 4 (even if that would be less than optimal). ;) I.e., you're focussed on maxsize, but the report covers both min & max. Any reason not to document that the default value of 4 is also the minimum allowed? I'm fine with dropping the patch as well.

its8511 - Fix documentation for multimaster, deprecate mirrormode

Gratuitous change, existing docs and practices are already established.
Hard enough to get people to update their docs, this is a bad idea.

This change is not gratuitous in the least.  The misinformation in our
current  documentation leads to constant confusion among end users, who
often do not  want to go to the lengths necessary to deploy the
*concept* that is mirror  mode, and instead just want to do
"multimaster", so they leave our current  misnamed 'mirrormode'
parameter set to false.  Fixing the documentation to  match the reality
of what's being configured is a positive step to removing  confusion and
to stop misleading end users on what is being done.  I've  provided
numerous links from the mailing list where this caused problems for  end
users before.  Our parameters should reflect what they actually do.

You're talking about confusion for new users, meanwhile you're just
creating confusion for existing users. Existing users tend to complain
more because they have more invested into their running deployments. This
is a bad idea.

Since it deprecates the existing parameter, it has no effect on current deployments. If anyone ends up confused due to the fact that the documentation was clarified to reflect objective reality, I'll be more than happy to help them. We already have endless complaints that our documentation is overly confusing. This fix helps address that problem.



Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: