DAOS-16829 control: fix for daos pool query

[wangshilong]

Get basic pool info firstly, then update other rank lists sequentially.

Features: DmgPoolQueryRanks
Test-tag: pool_query
Required-githooks: true

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 'Regression with pool/query_attribute.py functional test'
Status is 'In Review'
Labels: 'ci_master_weekly,weekly_test'
https://daosio.atlassian.net/browse/DAOS-16829

[knard38]

The overall PR seems good to me, however I am not sure on the pragma used which seems to restrictive for me. Instead of

Features: DmgPoolQueryRanks
Test-tag: pool_query

It should probably be better to use

Features: daos_cmd

[tanabarr]

please add a unit test that covers change in behaviour to avoid any regressions

[kjacque]

Logic looks reasonable, but I agree with Tom's comment that a unit test is needed.

[daosbuild1]

Test stage Functional Hardware Medium completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-15537/3/display/redirect

[wangshilong]

please add a unit test that covers change in behaviour to avoid any regressions

@tanabarr @kjacque I spent some time to add a unit test, but it looks test reply on C function daos_pool_query(), is there an example that I might follow how I could solve this(I am trying gomock)?

[daosbuild1]

Test stage Build on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15537/4/execution/node/381/log

[daosbuild1]

Test stage Build on Leap 15.5 with Intel-C and TARGET_PREFIX completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15537/4/execution/node/387/log

[daosbuild1]

Test stage Build RPM on EL 9 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15537/4/execution/node/377/log

[daosbuild1]

Test stage Build RPM on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15537/4/execution/node/373/log

[daosbuild1]

Test stage Build RPM on Leap 15.5 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15537/4/execution/node/369/log

[daosbuild1]

Test stage Build DEB on Ubuntu 20.04 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15537/4/execution/node/355/log

[wangshilong]

@Michael-Hennecke Feel free to go with your PR, i just leave it here in case something is useful for you. Thanks

[kjacque]

I'm really hesitant to approve a mocking approach that requires this much overhead.

Just a suggestion, but you could pass in the C function as a parameter instead, to achieve a similar goal:

// You will want to define a Go type for a long function signature like this, for readability.
type libdaosPoolQuery func(C.daos_handle_t, **C.d_rank_list_t, *C.daos_pool_info_t, *C.daos_prop_t, *C.daos_event_t) C.int

func queryPool(apiQuery libdaosPoolQuery, poolHdl C.daos_handle_t, queryMask daos.PoolQueryMask) (*daos.PoolInfo, error)

In src/control/cmd/daos/health.go:107, the line would then be:

    tpi, err := queryPool(C.daos_pool_query, poolHdl, queryMask)

In queryPoolRankLists, you would then call the function passed in without adding conditionals checking for mocking. You could then test queryPool by coming up with mock functions to pass in. It can be very simple. We just want to exercise the logic.

[kjacque]

Mocks should definitely not be in production code files. In general for Go code, we restrict mocks to their own files, or put them in test files.

[kjacque]

I'm not sure about this approach. I believe @mjmac still has a work in progress for making the underlying libdaos something mockable. I'd avoid adding something like this for now.

[wangshilong]

Hi Kris,

Thanks for input, generally I tried to use gomock, but it is a bit weird that existed codes did not use it..using go mock in production codes is a bit annoying. because when using cgo in pool_test.go is not allowed...

Anyway, I would consider this as a go experience for me. Since @Michael-Hennecke has another PR to fix this issue, I will abort this PR anyway.

I'm really hesitant to approve a mocking approach that requires this much overhead.

Just a suggestion, but you could pass in the C function as a parameter instead, to achieve a similar goal:

// You will want to define a Go type for a long function signature like this, for readability.
type libdaosPoolQuery func(C.daos_handle_t, **C.d_rank_list_t, *C.daos_pool_info_t, *C.daos_prop_t, *C.daos_event_t) C.int

func queryPool(apiQuery libdaosPoolQuery, poolHdl C.daos_handle_t, queryMask daos.PoolQueryMask) (*daos.PoolInfo, error)

In src/control/cmd/daos/health.go:107, the line would then be:

    tpi, err := queryPool(C.daos_pool_query, poolHdl, queryMask)

In queryPoolRankLists, you would then call the function passed in without adding conditionals checking for mocking. You could then test queryPool by coming up with mock functions to pass in. It can be very simple. We just want to exercise the logic.