-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DAOS-14781 test: expect more containers before rdb nospace #13647
Conversation
Change the server/metdata.py tests to expect, for a pool rdb capacity of 128 MiB, out of space errors just before creating a maxiimum of about 7500 containers (increasing from the prior value 3000). Test-tag: server,metadata Test-repeat: 5 Skip-unit-tests: true Skip-fault-injection-test: true Signed-off-by: Kenneth Cain <kenneth.c.cain@intel.com>
Bug-tracker data: |
Limited the scope of testing in this PR to just those test tags found in the ftest server/metadata.py (thus, the use of the forced-landing label in the PR). All server/metadata.py tests passed 5 times using the Test-repeat commit pragma. |
@@ -65,7 +65,7 @@ class ObjectMetadata(TestWithServers): | |||
CREATED_CONTAINERS_MIN = 2900 | |||
|
|||
# Number of created containers that should not be possible | |||
CREATED_CONTAINERS_LIMIT = 3500 | |||
CREATED_CONTAINERS_LIMIT = 7500 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just pointing out this might be a moving target in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. In some older discussions IIRC it was suggested to restructure the test to first probe for the number of create-able containers in a first pass, and then base any subsequent passes success criteria upon this discovered number (that there be some predictability e.g., as tested in the addremove test). Though I suppose there is some value in those constants in the current code do allow us to flag unexpected large changes such as this one. Thanks for the review & landing.
Change the server/metdata.py tests to expect, for a pool rdb capacity of 128 MiB, out of space errors just before creating a maxiimum of about 7500 containers (increasing from the prior value 3000). Test-tag: server,metadata Test-repeat: 5 Skip-unit-tests: true Skip-fault-injection-test: true Signed-off-by: Kenneth Cain <kenneth.c.cain@intel.com>
Change the server/metdata.py tests to expect, for a pool rdb capacity of 128 MiB, out of space errors just before creating a maxiimum of about 7500 containers (increasing from the prior value 3000). Test-tag: server,metadata Test-repeat: 5 Skip-unit-tests: true Skip-fault-injection-test: true Signed-off-by: Kenneth Cain <kenneth.c.cain@intel.com>
…13658) Change the server/metdata.py tests to expect, for a pool rdb capacity of 128 MiB, out of space errors just before creating a maxiimum of about 7500 containers (increasing from the prior value 3000). To avoid out of space errors on pool service replica followers, in the server/metadata.yaml functional test config, change the rdb log compaction frequency (RDB_COMPACT_THRESHOLD) to be once every 64 entries, rather than the prdoduct default 256. For applications that push the metadata/rdb space to its limits, this is one tactic to reduce the amount of free space skew between the leader and followers. Such skew, if allowed to become too large, can cause followers to run out of space in rdb before the next periodic trigger of log compaction. And that of course can impact overall pool service availability. Signed-off-by: Kenneth Cain <kenneth.c.cain@intel.com>
Change the server/metdata.py tests to expect, for a pool rdb capacity of 128 MiB, out of space errors just before creating a maxiimum of about 7500 containers (increasing from the prior value 3500).
Test-tag: server,metadata
Test-repeat: 5
Skip-unit-tests: true
Skip-fault-injection-test: true
Before requesting gatekeeper:
Features:
(orTest-tag*
) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.Gatekeeper: