daos-stack
DAOS-17503 control: Fix hello_drpc test
The hello_drpc test utility uses a sample message to test dRPC functionality. The tool was broken by some changes intended to be more strict about type safety. The logic was a bit too strict and duplicated checks that are the purview of the modules.
- Move DAOS dRPC module definitions into lib/daos package.
- Remove hard limitations on dRPC module values defined into the ModuleID type.
- Define module IDs as int32. The type no longer added anything.
- Move useful ModuleID functionality into the Module interface, for Module implementers to provide.
- Add a Go unit test to verify dRPC server/client integration.
Features: control
Steps for the author:
- [x] Commit message follows the guidelines.
- [ ] Appropriate Features or Test-tag pragmas were used.
- [ ] Appropriate Functional Test Stages were run.
- [ ] At least two positive code reviews including at least one code owner from each category referenced in the PR.
- [ ] Testing is complete. If necessary, forced-landing label added and a reason added in a comment.
After all prior steps are complete:
- [ ] Gatekeeper requested (daos-gatekeeper added as a reviewer).
Ticket title is 'Fix hello_drpc test infrastructure' Status is 'In Review' https://daosio.atlassian.net/browse/DAOS-17503
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'm hoping that we aren't losing anything by moving back to using plain ints in some places and guess that the net benefit of the changes is positive.
Thanks @tanabarr. I spent some time thinking about it, and just couldn't think of a reason to keep a ModuleID type when each Module knows everything there is to know about itself.
I felt like the GetMethod method and the Method-related types were creating an unnecessary redundancy, too, but they contain more logic and IMO require a little more thought to pull out. As-is it does feel a bit like a partial transition to a different design idea though, where Methods are self-contained, and the Module becomes more of a generic container for Methods. It's not a bad idea, given the amount of boilerplate in the Module implementations, but the current state isn't all the way there. Maybe something we can revisit later.
Test stage Functional on EL 8.8 completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-16350/6/execution/node/1141/log
Test stage Functional on EL 8.8 completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-16350/7/execution/node/460/log
Test stage Functional on EL 8.8 completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-16350/8/execution/node/1120/log
Test stage Functional Hardware Large MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-16350/9/execution/node/1382/log
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-16350/9/execution/node/1337/log
Test stage Functional Hardware Medium Verbs Provider MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-16350/10/execution/node/1382/log
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-16350/10/execution/node/1337/log
Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-16350/11/execution/node/1486/log