Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1450863
Description of problem: RFE: Warning logs when Autotuning of nsslapd-threadnumber above or below the optimal value When an admin set nsslapd-threadnumber values above or below value, warning should be logged to alert since it can be possible that the value might have been updated my mistake. Testing Result: - Default Value ---------------------------------------------------------------------------- [root@qe-blade-01 ~]# ldapsearch -h 127.0.0.1 -b "cn=config" -D "cn=Directory Manager" -w Secret123 nsslapd-threadnumber |grep -i nsslapd-threadnumber # requesting: nsslapd-threadnumber nsslapd-threadnumber: 32 ---------------------------------------------------------------------------- - Manual Change ---------------------------------------------------------------------------- [root@qe-blade-01 ~]# ldapmodify -h 127.0.0.1 -D "cn=Directory Manager" -w Secret123 -x << EOF dn: cn=config changetype: modify replace: nsslapd-threadnumber nsslapd-threadnumber:640 EOF modifying entry "cn=config" [root@qe-blade-01 ~]# ldapsearch -h 127.0.0.1 -b "cn=config" -D "cn=Directory Manager" -w Secret123 nsslapd-threadnumber |grep -i nsslapd-threadnumber # requesting: nsslapd-threadnumber nsslapd-threadnumber: 640 ---------------------------------------------------------------------------- Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-13.el7.x86_64 How reproducible: Always Actual results: No warning is logged when nsslapd-threadnumber is changed with count below or above the optimal value. Expected results: Warning should be logged when nsslapd-threadnumber is changed with count below or above the optimal value. Additional info:
Metadata Update from @mreynolds: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1450863
Why? If someone wants to set these values why not let them? autotuning is mean to be "good enough", but if someone has a requirement for more or less why not let them?
Metadata Update from @firstyear: - Custom field type adjusted to defect
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.7.0 (was: 0.0 NEEDS_TRIAGE)
Metadata Update from @mreynolds: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Issue set to the milestone: 1.4 backlog (was: 1.3.7.0)
Metadata Update from @mreynolds: - Issue assigned to mreynolds
Well some Admin's might think more threads is better. I don't think it would hurt to say, hey this is potentially too high or too low for your own good :-)
https://pagure.io/389-ds-base/pull-request/51173
Commit a64d6be relates to this ticket
58699ec..16203a1 389-ds-base-1.4.3 -> 389-ds-base-1.4.3
8b7a1cd..bcb79d9 389-ds-base-1.4.2 -> 389-ds-base-1.4.2
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue priority set to: normal - Issue set to the milestone: 1.4.2 (was: 1.4 backlog) - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2315
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.