CONCLUSION:
It may be that filter optimisation is highlighting incorrect ipa queries by executing
their components in a different yet valid order, rather than actually causing corruption
or other issues. It could be that we have allowed such queries to evaluate as true due to
a mistake in the application of the filter test in our search code.
I think in many cases grok-filter here may be helping to set can_skip to false, but I also
can’t eliminate this as a possibility: I can’t reproduce it, but the code doesn’t seem
right either.
I think I may harden it in the patch, improve the debugging some more, and set “verify” to
true to see if there is some failing condition in the IPA code path.
Part of the issue is I really don’t know what query is the failing one, nor what IPA is
actually expecting to see as a result here. Perhaps this is a case where I need someone
from FreeIPA to actually determine *exactly* what query is failing to help isolate the
problem, because today, I’m just feeling a bit lost and not able to see what’s failing -
the access logs to me look like they are all okay. So some ideas on how I can progress to
analyse this would be great, as I think having this would really help IPA especially with
query processing performance (and it’s a step toward further improvements.)
Thanks everyone,
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs