DAOS-16712 test: Fix list_verbose mem_file_bytes comparison

[tanabarr]

In any case that is not MD-on-SSD phase-2, mem_file_bytes should equal scm_size.

Test-tag: ListVerboseTest Required-githooks: true

Before requesting gatekeeper:

• [ ] Two review approvals and any prior change requests have been resolved.
• [ ] Testing is complete and all tests passed or there is a reason documented in the PR why it should be force landed and forced-landing tag is set.
• [ ] Features: (or Test-tag*) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.
• [ ] Commit messages follows the guidelines outlined here.
• [ ] Any tests skipped by the ticket being addressed have been run and passed in the PR.

Gatekeeper:

• [ ] You are the appropriate gatekeeper to be landing the patch.
• [ ] The PR has 2 reviews by people familiar with the code, including appropriate owners.
• [ ] Githooks were used. If not, request that user install them and check copyright dates.
• [ ] Checkpatch issues are resolved. Pay particular attention to ones that will show up on future PRs.
• [ ] All builds have passed. Check non-required builds for any new compiler warnings.
• [ ] Sufficient testing is done. Check feature pragmas and test tags and that tests skipped for the ticket are run and now pass with the changes.
• [ ] If applicable, the PR has addressed any potential version compatibility issues.
• [ ] Check the target branch. If it is master branch, should the PR go to a feature branch? If it is a release branch, does it have merge approval in the JIRA ticket.
• [ ] Extra checks if forced landing is requested
  • [ ] Review comments are sufficiently resolved, particularly by prior reviewers that requested changes.
  • [ ] No new NLT or valgrind warnings. Check the classic view.
  • [ ] Quick-build or Quick-functional is not used.
• [ ] Fix the commit message upon landing. Check the standard here. Edit it to create a single commit. If necessary, ask submitter for a new summary.

[github-actions[bot]]

Ticket title is 'pool/list_verbose.py:ListVerboseTest.test_used_imbalance - mem_file_bytes differ ' Status is 'In Review' Labels: 'weekly_test,md_on_ssd2' https://daosio.atlassian.net/browse/DAOS-16712

[tanabarr]

Do we need to also run with md on ssd?

Skip-func-hw-test-medium-md-on-ssd: false

that makes sense yes, really we should be running those stages with all PRs targeted at the feature branch, any way of turning that on/making it automatic?

[daltonbohning]

Do we need to also run with md on ssd?

Skip-func-hw-test-medium-md-on-ssd: false

that makes sense yes, really we should be running those stages with all PRs targeted at the feature branch, any way of turning that on/making it automatic?

Yes, here: https://github.com/daos-stack/daos/blob/589dbf4d0f67768ad7054d8e7047f7016e01bd94/Jenkinsfile#L1188

But the tricky part is if you do this

Test-tag: a lot of tests

Then both the pmem and md on ssd stages will run all those tests. So it can be a burden on CI if not careful

[daosbuild1]

Test stage Functional on EL 8.8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15344/2/execution/node/1200/log

[tanabarr]

Do we need to also run with md on ssd?

Skip-func-hw-test-medium-md-on-ssd: false

that makes sense yes, really we should be running those stages with all PRs targeted at the feature branch, any way of turning that on/making it automatic?

Yes, here:

https://github.com/daos-stack/daos/blob/589dbf4d0f67768ad7054d8e7047f7016e01bd94/Jenkinsfile#L1188

But the tricky part is if you do this

Test-tag: a lot of tests

Then both the pmem and md on ssd stages will run all those tests. So it can be a burden on CI if not careful

I meant running them if pr is targeted at feature branch

[daosbuild1]

Test stage Functional Hardware Medium MD on SSD completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15344/3/testReport/

[daosbuild1]

Test stage Functional Hardware Medium completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15344/3/testReport/

[phender]

@tanabarr looks like you're running into https://daosio.atlassian.net/browse/DAOS-16669 with https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-15344/3/testReport/

[daosbuild1]

Test stage Functional Hardware Medium completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15344/4/testReport/

[phender]

Do we need to also run with md on ssd?

Skip-func-hw-test-medium-md-on-ssd: false

that makes sense yes, really we should be running those stages with all PRs targeted at the feature branch, any way of turning that on/making it automatic?

Yes, here: https://github.com/daos-stack/daos/blob/589dbf4d0f67768ad7054d8e7047f7016e01bd94/Jenkinsfile#L1188

But the tricky part is if you do this

Test-tag: a lot of tests

Then both the pmem and md on ssd stages will run all those tests. So it can be a burden on CI if not careful

I meant running them if pr is targeted at feature branch

I've been thinking about this lately and ideally any HW test using storage: auto in their server config should be run in both PMEM and MD on SSD stages. With our ability to parse the tags from modified ftest files in the pr we could enable setting both:

Skip-func-hw-test-medium-md-on-ssd: false
Skip-func-hw-test-large-md-on-ssd: false

automatically in the commit pragma. If parsing the test yaml to find storage:auto proves too expensive we could just add a tag like uses_storage_auto and pay the maintenance cost of it.

[tanabarr]

landing because it's already had a successful run without any code change since