DAOS-15628-test: Verify maximum containers create with and without dup metadata ops

[dinghwah]

Description: implement more test to metadata with disable svc.

Skip-unit-tests: true
Skip-fault-injection-test: true
Test-tag: ObjectMetadata
Doc-only: false
Required-githooks: true
Signed-off-by: Ding Ho ding-hwa.ho@intel.com

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]

Errors are component not formatted correctly,Title of PR is too long,Ticket number suffix is not a number. See https://daosio.atlassian.net/wiki/spaces/DC/pages/11133911069/Commit+Comments,Unable to load ticket data
https://daosio.atlassian.net/browse/DAOS-15628-test:

[daosbuild1]

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

[daosbuild1]

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

[daosbuild1]

Test stage Test RPMs on EL 8.6 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-14145/6/display/redirect

[kccain]

Jenkins build 8 https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-14145/8/artifact/Functional%20Hardware%20Large/server/metadata.py/results.json seems to have run 2 configurations for test_metadata_addremove and test_metadata_server_restart, which is not desired. The total runtime went to 3500+ seconds, compared to a typical weekly run duration of 1500+ seconds (for example https://build.hpdd.intel.com/job/daos-stack/job/daos/job/weekly-testing/378/artifact/Functional%20Hardware%20Large/server/metadata.py/results.json) . Only muxing for test_metadata_fillup is desired.

[daltonbohning]

Jenkins build 8 https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-14145/8/artifact/Functional%20Hardware%20Large/server/metadata.py/results.json seems to have run 2 configurations for test_metadata_addremove and test_metadata_server_restart, which is not desired. The total runtime went to 3500+ seconds, compared to a typical weekly run duration of 1500+ seconds (for example https://build.hpdd.intel.com/job/daos-stack/job/daos/job/weekly-testing/378/artifact/Functional%20Hardware%20Large/server/metadata.py/results.json) . Only muxing for test_metadata_fillup is desired.

I don't think we can use mux for a single test method. We'd have to either move that test to a different file or split the test case into multiple methods in the same file

[daosbuild1]

Test stage Functional Hardware Large completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14145/10/execution/node/880/log

[daltonbohning]

We shouldn't conditionally run the test, and the default is enabled, so we should be able to just run this

Suggested change

	# Skip dummy_metadata_workload when feature is disabled
	svc_ops_enabled = self.pool.get_property("svc_ops_enabled")
	if svc_ops_enabled:
	svc_ops_entry_age = self.pool.get_property("svc_ops_entry_age")
	if not self.run_dummy_metadata_workload(duration=svc_ops_entry_age):
	self.fail("failed to run dummy metadata workload")
	svc_ops_entry_age = self.pool.get_property("svc_ops_entry_age")
	if not self.run_dummy_metadata_workload(duration=svc_ops_entry_age):
	self.fail("failed to run dummy metadata workload")

[dinghwah]

The suggestion does not work, since svc_ops_entry_age could be a valid number (ie: 60, or 300...) and svc_ops_enabled is disabled and causing issue.

[daltonbohning]

This calls self.create_pool()
Which has

def create_pool(self, svc_ops_enabled=True):
...
    if svc_ops_enabled:
        self.add_pool()   

So svc_ops_enabled is turned on

[dinghwah]

no. With the suggested 390-392, when svc_ops_enabled=False, the run_metsdata_dummy_workload will be executed.

[daltonbohning]

How would svc_ops_enabled=False? The default is True and this test doesn't pass False

[daltonbohning]

This is test_metadata_addremove

[dinghwah]

Yes. To determine running dummy_workload should check for svc_ops_enabled or not, not svc_ops_entry_age.

[daltonbohning]

svc_ops_enabled isn't dynamic here. It's always what is set in the config

daos/src/tests/ftest/server/metadata.yaml

Line 53 in 05474cf

properties: svc_ops_enabled:1,svc_ops_entry_age:60

[dinghwah]

Yes. This is true. However, your suggestion is wrong.
In order to is to reduce test run time, we decide not to use !mux to run svc_ops_disabled testcase for test_metadata_addremove. We might need to run manual testcase later.

[kccain]

For test_metadata_addremove(), for simplicity, I think we always want to run one variant (in this case, let's say we decide to use svc_ops_enabled:1 and run a dummy workload loop of svc_ops_entry_age seconds).

Which makes me wonder if in the .yaml file, maybe it should not specify svc_ops_enabled in the pool properties at all. And just leave it to the test cases in this code to specify in the argument to add_pool() whether svc_ops_enabled shall be True or False?

test_metadata_fillup_svc_ops_disabled and test_metadata_fillup_svc_ops_enabled already pass in the argument explicity.
test_metadata_addremove already effectively does the same (no argument means the default svc_ops_enabled=True is used).

[daltonbohning]

Suggested change

	svc_ops_enabled (bool): Pool create properties svc_ops_enabled, default to True.
	svc_ops_enabled (bool): Pool create properties svc_ops_enabled. Defaults to True.

[dinghwah]

Updated.

[daltonbohning]

We shouldn't be adding numbers when using log_step because log_step already adds numbers

[dinghwah]

The reason to add 1. 2. 3.... for the step is sync with the test steps in the testcase description.

[daltonbohning]

But this output is confusing
https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-14145/12/artifact/Functional%20Hardware%20Large/server/metadata.py/steps.log

Step 5: 1. Create pool with properties svc_ops_enabled: True [elapsed since last step: 0.00s]
Step 6: 2. sustained container creates: to no space and beyond. [elapsed since last step: 66.16s]
Step 7: 3. Verify number of container within limit. [elapsed since last step: 114.49s]
Step 8: 4. Cleaning up 500 containers after pool is full. [elapsed since last step: 0.00s]

[dinghwah]

I think it's clear. the global Step 5, and the testcase step 1.

[daltonbohning]

@phender opinion?

[daltonbohning]

Similar - we shouldn't add numbers to self.fail because they probably won't correspond to the numbers that log_step automatically adds

[dinghwah]

Same, to add #1... would be easier for later debug.

[daltonbohning]

We should simplify this since we only have 1 variant running

Suggested change

	pool_prop: !mux
	svc_ops_60:
	properties: svc_ops_enabled:1,svc_ops_entry_age:60
	properties: svc_ops_enabled:1,svc_ops_entry_age:60

[dinghwah]

Sorry, we have to use the !mux for the other testcases (150, 300, and 600) which currently commented out for manual test to reduce CI test time.

[daltonbohning]

It's not just CI time - it's also that mux applies to every test method. So turning those on, even for manual, means running duplicate test cases. Do we have plans to run some of these manually?

[dinghwah]

Multiple svc_ops_entry_age (60,150, 300, and 600) is on the test plan.
@kccain, please comment.

[kccain]

If the mux is controversial with only one variant running, can the mux be removed from the file, and the comments specify to uncomment just ONE configuration to (during manual execution) change the svc_ops_entry_age property value?

[kccain]

added my comments, I hope they are helpful. There is a lot of activity in the PR

I do realize this one was closed, not sure why. But I figured it would be more valuable to add my comments here with the other comments submitted so far.

[kccain]

I think this should be 2 instead of 3confused about all the numbering changes
but assuming you keep all of that, I think this should be 2 instead of 3

[kccain]

I think this should be 2 instead of 3

[kccain]

I think this should be 2 instead of 3

[kccain]

should be 3 instead of 4

[kccain]

should be 3 instead of 4

[kccain]

suggest description (here, and in the test_* functions below) be changed to something like
Run test to verify number of resources that can be created until metadata is full.

[kccain]

If the mux is controversial with only one variant running, can the mux be removed from the file, and the comments specify to uncomment just ONE configuration to (during manual execution) change the svc_ops_entry_age property value?

[kccain]

Also might add that the values of created_cont_min and created_cont_max will be affected by the duration of the svc_ops_entry_age, so they may need to be adjusted accordingly.

[kccain]

For test_metadata_addremove(), for simplicity, I think we always want to run one variant (in this case, let's say we decide to use svc_ops_enabled:1 and run a dummy workload loop of svc_ops_entry_age seconds).

Which makes me wonder if in the .yaml file, maybe it should not specify svc_ops_enabled in the pool properties at all. And just leave it to the test cases in this code to specify in the argument to add_pool() whether svc_ops_enabled shall be True or False?

test_metadata_fillup_svc_ops_disabled and test_metadata_fillup_svc_ops_enabled already pass in the argument explicity.
test_metadata_addremove already effectively does the same (no argument means the default svc_ops_enabled=True is used).

[dinghwah]

Thanks for the comments.
After discussed with Phil and met with Ken:
#14243 should have addressed all the above issues and comments. Please review PR-14243 if I missed anything.