DAOS-17001 rebuild: when self_heal is set to delay_rebuild, do not re…

[cdavis28]

…build on exclude

delay_rebuild mode should delay the rebuild in all scenarios and not have an exception for target exclusion. Also changed an error message to warn on shard update failure. Shard update failure is normal during a failure, and the message was too frequent.

Testing:
dmg pool exclude default-pool --rank 0 --target-idx 4 while write/read workflow was running against a cluster

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]

Ticket title is 'Target exclusion with delay_rebuild set'
Status is 'In Progress'
Labels: 'google-cloud-daos'
https://daosio.atlassian.net/browse/DAOS-17001

[jolivier23]

Only question I have....do we need any extra check here? For stuff like reintegrate or drain or extend, we actually do want rebuild. But I will defer to Di who is infinitely more familiar with the logic here

[kccain]

Yeah, I am also curious about this, too. It seems another check is needed.
So the goal of the patch is to make sure to have a delayed rebuild for any type of exclusion whether initiated by SWIM detection of a lost engine (already handled), or administratively excluded targets (e.g., via dmg pool exclude command).

Maybe logic such as the following would do what is needed here, to not impact reintegrate, drain, and extend?

if ((entry->dpe_val & DAOS_SELF_HEAL_DELAY_REBUILD) && (opc == MAP_EXCLUDE))

Now that I look at this, it seems maybe there is a bug in the DAOS_REINT_MODE_NO_DATA_SYNC branch above when it tests opc to see if it is POOL_EXCLUDE or POOL_DRAIN. I think instead the test there should be for MAP_EXCLUDE or MAP_DRAIN, since the caller converts the RPC opcodes (POOL_) into pool map opcodes (MAP_) that have different values (!).

[daosbuild1]

Test stage Functional Hardware Medium Verbs Provider completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15809/3/execution/node/1467/log

[daosbuild1]

Test stage Functional Hardware Medium completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15809/3/execution/node/1457/log