Repository navigation
Conversation
|
Ticket title is 'Extend test_dmg_system_reformat to verify operation with multiple replicas' |
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/1/execution/node/1140/log |
b16c487 to
47c67cd
Compare
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/3/execution/node/1161/log |
| pool: !mux | ||
| default: | ||
| size: 90% | ||
| md_on_ssd_p2: | ||
| size: 90% | ||
| mem_ratio: 25 |
There was a problem hiding this comment.
Since the same test can be run on a cluster configured with PMEM and a cluster configured to use MD on SSD, we cannot simply mux the two pool commands because the one with --mem-ratio will fail when the test is run on the cluster configured with PMEM.
To handle this, we use the filter-only feature in the test yaml (see example in ior/small.yaml), e.g.
launch:
!filter-only : /run/pool/default # yamllint disable-line rule:colons
pool: !mux
default:
size: 100%
properties: rd_fac:0,space_rb:0
md_on_ssd_p2:
size: 100%
properties: rd_fac:0,space_rb:0
mem_ratio: 50
When the test is run launch.py optionally adds an extra yaml file that includes:
launch:
!filter-only : /run/pool/md_on_ssd_p2
when it is being run with MD on SSD. This enables the second variant that creates a pool with --mem-ratio. On a cluster configured to use PMEM, this optional extra yaml is not created and only the default pool variant is run.
| engines: | ||
| 0: | ||
| storage: auto | ||
| system_ram_reserved: 32 |
There was a problem hiding this comment.
Do we need reserved ram on HW clusters? I thought we have been removing this from tests that run on HW clusters.
|
Test stage Functional Hardware Large MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/4/execution/node/1142/log |
487619c to
0530576
Compare
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/6/execution/node/1160/log |
6c03e6d to
ae11d67
Compare
0530576 to
9512258
Compare
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos/job/PR-19191/8/display/redirect |
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/9/execution/node/659/log |
de5bbdf to
2a95e0c
Compare
9512258 to
c3a278d
Compare
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/10/execution/node/1117/log |
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/13/execution/node/1391/log |
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/14/execution/node/1134/log |
7477149 to
3bacfa7
Compare
da7f094 to
a25042e
Compare
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/15/execution/node/1134/log |
39aed85 to
9c5c444
Compare
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/18/execution/node/1578/log |
|
Test stage Unit Test completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos/job/PR-19191/19/display/redirect |
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/20/execution/node/1594/log |
…eplicas Test-tag: hw,medium,control,dmg,system_reformat Signed-off-by: Tom Nabarro <thomas.nabarro@hpe.com>
Test-tag: test_dmg_system_reformat Signed-off-by: Tom Nabarro <thomas.nabarro@hpe.com>
…ted failures Test-tag: test_dmg_system_reformat Signed-off-by: Tom Nabarro <thomas.nabarro@hpe.com>
Test-tag: test_dmg_system_reformat Signed-off-by: Tom Nabarro <thomas.nabarro@hpe.com>
execControlPlaneRestart's GracefulStop()/Stop() sequence has been observed to hang indefinitely in CI (dmg_system_reformat.py multi-replica cases), with no visibility into what is blocking progress. Add goroutine stack dumps on GracefulStop() timeout and on a new Stop() timeout, plus explicit before/after logging around Stop(), and stop waiting on Stop() past gracefulStopTimeout so the exec() restart is never blocked indefinitely by a stuck Stop() call. Test-tag: test_dmg_system_reformat Signed-off-by: Tom Nabarro <thomas.nabarro@hpe.com>
ca91f84 to
02c6808
Compare
|
Test stage Unit Test completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos/job/PR-19191/21/display/redirect |
2372ef4 to
70be471
Compare
|
@phender @daltonbohning probably ready for you guys to take a look please, it should be passing now |
Features: control Signed-off.-by: Tom Nabarro <thomas.nabarro@hpe.com>
70be471 to
58119b0
Compare
|
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19191/24/execution/node/2013/log |
Test-tag: test_dmg_system_reformat Signed-off-by: Tom Nabarro <thomas.nabarro@hpe.com>
Extend DmgSystemReformatTest to cover dmg system erase/reformat across
storage modes (PMem/MD-on-SSD) and MS replica counts, instead of a
single fixed configuration.
Bump test_servers to 3 and add a setup: !mux single/multi_replica axis
varying mgmt_svc_replicas_qty.
Add a server_config: !mux standard/non_standard axis varying system
name and control port.
Add a pool: !mux default/md_on_ssd_p2 axis with a mem_ratio variant.
Add get_replicas() to assert the MS replica set is unchanged across
erase/reformat.
Wait for engine restart on every server_manager, not just the last.
Drop --force from system stop/storage format; retry format with a
longer timeout, tolerating a late "already running" response.
Fix system name forwarding on SystemErase's membership check and
replica fanout, which dropped non-default system names; authorise
SystemQuery for ComponentServer accordingly.
Add goroutine-stack diagnostics and a bounded Stop() wait to
execControlPlaneRestart to diagnose and avoid CI hangs during
multi-replica erase.
Features: control
Steps for the author:
After all prior steps are complete: