#49256 RFE: Warning logs when Autotuning of nsslapd-threadnumber above or below the optimal value
Closed: wontfix by mreynolds. Opened by mreynolds.

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

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

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?

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 a64d6be1 relates to this ticket

Commit a64d6be relates to this ticket

58699ec81..16203a191 389-ds-base-1.4.3 -> 389-ds-base-1.4.3

8b7a1cd18..bcb79d93b 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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

Metadata
Related Pull Requests