DAOS-9584 chk: Add srv handlers for checker upcalls #8579
Conversation
The TestDatabase only needs to be set up once for the whole suite. Signed-off-by: Michael MacDonald <[email protected]>
|
Test stage checkpatch completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-8579/2/execution/node/98/log |
Implement control plane handlers for the following engine checker dRPC upcalls: * CheckerListPools * CheckerRegisterPool * CheckerDeregisterPool Signed-off-by: Michael MacDonald <[email protected]>
| return | ||
| } | ||
|
|
||
| ps := &system.PoolService{ |
There was a problem hiding this comment.
@Nasf-Fan: I think we can add it later, but we should probably also have the full set of known storage ranks as part of this information. The MS stores this information for later use during pool destroy/cleanup. We also can store some information about the per-rank tier storage allocations (scm/nvme), but we don't really do anything with it right now.
| case drpc.MethodCheckerRegisterPool: | ||
| return mod.handleCheckerRegisterPool(ctx, req) | ||
| case drpc.MethodCheckerDeregisterPool: | ||
| return mod.handleCheckerDeregisterPool(ctx, req) |
There was a problem hiding this comment.
@Nasf-Fan: Hmm, thinking about this a little more, we probably need an upcall to fix a pool too, right? E.g. in the case where the label stored in the pool properties does not match the label stored in the MS. Or the svc ranks are wrong, etc.
I suppose the checker could also just ask the MS to deregister the old pool and register a new pool with the fixed values. Maybe that's simpler. But as I noted in the other comment we may lose information that way.
In many (most?) cases the upcall handlers do return more specific status codes for what are probably the most likely errors (e.g. DER_EXIST, DER_INVALID, etc). We could probably do more to inspect the errors for other failures (e.g. |
Implement control plane handlers for the following
engine checker dRPC upcalls:
Signed-off-by: Michael MacDonald [email protected]