test_133 fails:
failed to add OST[0-14] to the pool

'lctl pool_add lustre.testpool OST[0-14]' (poolostrange = OSTCOUNT - 2 = 14 with the 16 OSTs this cluster has) returned:
pool_add: lustre-OST0010_UUID is not part of the 'lustre' fs.
pool_add: lustre-OST0011_UUID is not part of the 'lustre' fs.
pool_add: lustre-OST0012_UUID is not part of the 'lustre' fs.
pool_add: lustre-OST0013_UUID is not part of the 'lustre' fs.
pool_add: lustre-OST0014_UUID is not part of the 'lustre' fs.

lctl expanded the decimal range [0-14] to the literal zero-padded strings 0000..0014 instead of converting decimal indices 10-14 to their hex OST names (000a-000e). The real OSTs are named OST0000-OST000f (16 OSTs, hex), so OST0010-OST0014 do not exist and pool_add reports them as not part of the fs, failing the test. test_133 only requires OSTCOUNT >= 4 and has presumably always run with fewer than 10 OSTs in ordinary CI, never exercising a two-digit range.

Not this patch's: the diff under review does not touch conf-sanity.sh's test_133 or create_pool(), and it makes no change to lctl's pool_add range parsing; it is limited to test-framework.sh/functions.sh node-list helpers.

Maloo: https://testing.whamcloud.com/test_sets/12b03951-22b4-42bd-bca0-7b0147c3eafc (test_133)

Raised by Patch Watcher run pw-engineer-51976-ps6-684d26660414 on https://review.whamcloud.com/51976