Check the ports availability and go for a new port if the current one is
not available
Fixes: https://tracker.ceph.com/issues/62972
Signed-off-by: Nizamudeen A <nia@redhat.com>
qa/suites/orch: add a tests for testing public_addr for smb cluster create cmd
Reviewed-by: Adam King <adking@redhat.com>
Reviewed-by: John Mulligan <jmulligan@redhat.com>
This (already deprecated) module is removed as a side-effect of the
deprecation and removal of the `restful` module.
Fixes: https://tracker.ceph.com/issues/47066
Signed-off-by: Ernesto Puerta <epuertat@redhat.com>
src/common : proper handling of units in `strict_iec_cast`
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Rishabh Dave <ridave@redhat.com>
Reviewed-by: Dhairya Parmar <dparmar@redhat.com>
We don't support balanced reads on ec pools. Additionally, the yaml
actually specifies 'balanced_reads' rather than 'balance_reads' and
therefore has no actual effect.
Signed-off-by: Samuel Just <sjust@redhat.com>
Normally, the fs suite overrides the kernel branch whenever the kernel client
is used, according to the matrix of configs. This prevents easily testing a new
kernel with the -k option to teuthology-suite. So, using the base config passed
to the script, detect if an alternate testing kernel is desired and use that
instead.
The scheduler still needs to do some work:
$ teuthology-suite ... --verbose -k wip-pdonnell-i66704 --filter k-testing
...
2024-10-18 00:29:43,875.875 DEBUG:teuthology.suite.merge:base kernel {'branch': 'wip-pdonnell-i66704', 'kdb': 1, 'sha1': '745cacd8f31e50d7f3b6039bbd8c9a8dfc07bf03', 'flavor': 'default'}
2024-10-18 00:29:43,875.875 DEBUG:teuthology.suite.merge:overriding testing kernel with {'branch': 'wip-pdonnell-i66704', 'kdb': 1, 'sha1': '745cacd8f31e50d7f3b6039bbd8c9a8dfc07bf03', 'flavor': 'default'}
vs.
$ teuthology-suite ... --verbose --filter k-testing
...
2024-10-17 20:04:52,265.265 DEBUG:teuthology.suite.merge:base kernel {'branch': 'distro', 'kdb': 1, 'sha1': 'distro'}
Which will only select jobs using the "testing" kernel.
See-also: https://github.com/ceph/teuthology/pull/2008
Fixes: https://tracker.ceph.com/issues/68603
Signed-off-by: Patrick Donnelly <pdonnell@ibm.com>
Add qa/workunits/nvmeof/mtls_test.sh which enables
mtls config and redeploy, then verify and disables
mtls config.
Signed-off-by: Vallari Agrawal <vallari.agrawal@ibm.com>
qa/cephfs: ignore when specific OSD is reported down during upgrade
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
The OSD's IOPS capacity is used by the mClock scheduler to determine the
quantum of bandwidth allocation for the various operations on the OSD.
Prior to this commit, maybe_override_max_osd_capacity_for_qos() only
checked if the measured IOPS capacity exceeded the higher threshold defined
by 'osd_mclock_iops_capacity_threshold_[hdd|ssd]' and if so fallback to the
last valid or the default IOPS capacity as defined by
osd_mclock_max_capacity_iops_[hdd|ssd].
It's quite possible that the reported IOPS is unrealistically low. This
could be due to transient factors on the underlying device or it could
indicate bad health of the device. Either way, the safer option would be
to fallback to the last valid or the default IOPS setting for that OSD in
order to avoid cluster performance (slow or stalled ops) issues down the
line.
Therefore, to handle this case, the commit introduces additional config
options viz.,
- osd_mclock_iops_capacity_low_threshold_hdd - set to 50 IOPS and
- osd_mclock_iops_capacity_low_threshold_ssd - set to 1000 IOPS
If the measured IOPS capacity doesn't fall within the low and high
threshold range, the default or the last valid IOPS capacity is used.
The existing cluster log warning is suitably modified to convey the
reason.
Additionally, for a couple of valgrind related teuthology tests, the
cluster warning is added to the ignorelist since the reported IOPS can
be very low due to slowness.
Fixes: https://tracker.ceph.com/issues/67421
Signed-off-by: Sridhar Seshasayee <sseshasa@redhat.com>
