DAOS-14669 test: switch tcp;ofi_rxm testing to tcp

[soumagne]

Test-provider: ofi+tcp
Test-provider-hw-medium: ofi+tcp
Test-provider-hw-large: ofi+tcp
Test-tag: full_regression
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 watchers.
• 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.

[daosbuild1]

LGTM. No errors found by checkpatch.

[github-actions]

Bug-tracker data:
Ticket title is 'Enable regular testing of tcp provider (without rxm)'
Status is 'Open'
Labels: 'triaged'
https://daosio.atlassian.net/browse/DAOS-14669

[daosbuild1]

Test stage NLT on EL 8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-13365/1/testReport/

[daosbuild1]

Test stage Functional on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-13365/1/execution/node/1162/log

[daosbuild1]

LGTM. No errors found by checkpatch.

[daosbuild1]

Test stage Functional on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-13365/2/execution/node/1156/log

[daosbuild1]

LGTM. No errors found by checkpatch.

[daosbuild1]

Test stage Functional on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-13365/3/execution/node/1156/log

[github-actions]

Ticket title is 'Enable regular testing of tcp provider (without rxm)'
Status is 'Open'
Labels: 'triaged'
https://daosio.atlassian.net/browse/DAOS-14669

[daltonbohning]

We also need to run these two modified tests

Features: ConfigGenerateOutput ConfigGenerateRun

FYI I'm close to having that automated

[frostedcmos]

minor stuff inline

[frostedcmos]

not part of your change, but this should be also reading out D_PROVIDER .. ugh..

[soumagne]

yeah agree but nothing has been converted yet (even if you make it sound like it should have been? a grep of CRT_PHY_ADDR_STR shows me tons of files still have it) so I won't be addressing this in this PR. That should be done properly in a separate PR.

[mchaarawi]

some of the hw medium tests did not run with tcp provider and ran with verbs:
https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-13365/8/artifact/Functional%20Hardware%20Medium%20Verbs%20Provider/daos_test/suite.py/job.log
@daltonbohning @phender is there a tcp version of daos_test suite that runs in weekly?

[daltonbohning]

some of the hw medium tests did not run with tcp provider and ran with verbs: https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-13365/8/artifact/Functional%20Hardware%20Medium%20Verbs%20Provider/daos_test/suite.py/job.log @daltonbohning @phender is there a tcp version of daos_test suite that runs in weekly?

Ah, right. That's because the "Verbs Provider" stage hardcodes verbs.
There is a branch that runs pr and daily with tcp:
https://build.hpdd.intel.com/blue/organizations/jenkins/daos-stack%2Fdaos/detail/provider-testing-tcp/103/pipeline/52

I think for this PR we could push a commit that temporarily updates this:

daos/Jenkinsfile

Line 1179 in 1349dbf

provider: 'ofi+verbs;ofi_rxm',

Or maybe just push a separate PR since this one already has a clean run. Thoughts @phender?

[mchaarawi]

some of the hw medium tests did not run with tcp provider and ran with verbs: https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-13365/8/artifact/Functional%20Hardware%20Medium%20Verbs%20Provider/daos_test/suite.py/job.log @daltonbohning @phender is there a tcp version of daos_test suite that runs in weekly?

Ah, right. That's because the "Verbs Provider" stage hardcodes verbs. There is a branch that runs pr and daily with tcp: https://build.hpdd.intel.com/blue/organizations/jenkins/daos-stack%2Fdaos/detail/provider-testing-tcp/103/pipeline/52

I think for this PR we could push a commit that temporarily updates this:

daos/Jenkinsfile

Line 1179 in 1349dbf

provider: 'ofi+verbs;ofi_rxm',

Or maybe just push a separate PR since this one already has a clean run. Thoughts @phender?

yea we don't want to run
Functional%20Hardware%20Medium%20Verbs%20Provider test stage.
It sounds too complicated of a process to run a test stage with a different provider. I thought we have a test stage that we can manually add with a commit pragma that would run
FunctionalHardwareMediumTCProvider ?

[phender]

some of the hw medium tests did not run with tcp provider and ran with verbs: https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-13365/8/artifact/Functional%20Hardware%20Medium%20Verbs%20Provider/daos_test/suite.py/job.log @daltonbohning @phender is there a tcp version of daos_test suite that runs in weekly?

The Functional Hardware Medium Verbs Provider stage always runs with verbs via https://github.com/daos-stack/daos/blob/master/Jenkinsfile#L1179. It is not overridable, nor would we want it to because then the stage name wouldn't make sense. This stage only runs the daos_test/suite.py test and that test is currently run with tcp in the provider-testing-tcp branch. This branch makes use of the https://github.com/daos-stack/daos/blob/master/src/tests/ftest/util/network_utils.py#L25 alias to currently run with ofi+tcp;ofi_rxm (it uses --provider=ofi+tcp) - which is handled in this PR.

[phender]

some of the hw medium tests did not run with tcp provider and ran with verbs: https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-13365/8/artifact/Functional%20Hardware%20Medium%20Verbs%20Provider/daos_test/suite.py/job.log @daltonbohning @phender is there a tcp version of daos_test suite that runs in weekly?

Ah, right. That's because the "Verbs Provider" stage hardcodes verbs. There is a branch that runs pr and daily with tcp: https://build.hpdd.intel.com/blue/organizations/jenkins/daos-stack%2Fdaos/detail/provider-testing-tcp/103/pipeline/52
I think for this PR we could push a commit that temporarily updates this:

daos/Jenkinsfile

Line 1179 in 1349dbf

provider: 'ofi+verbs;ofi_rxm',

Or maybe just push a separate PR since this one already has a clean run. Thoughts @phender?

I thought we have a test stage that we can manually add with a commit pragma that would run FunctionalHardwareMediumTCProvider ?

That stage is only defined in the https://build.hpdd.intel.com/job/daos-stack/job/daos/job/provider-testing-tcp branch. In order to run that stage with these code changes we need the RPMs built from this PR available in artifactory so we can specify them in the CI_RPM_TEST_VERSION build parameter.

Alternatively, for testing purposes we could add a Functional Hardware Medium TCP Provider stage to the master Jenkinsfile, e.g.

                        'Functional Hardware Medium TCP Provider': getFunctionalTestStage(
                            name: 'Functional Hardware Medium TCP Provider',
                            pragma_suffix: '-hw-medium-tcp-provider',
                            label: params.FUNCTIONAL_HARDWARE_MEDIUM_TCP_PROVIDER_LABEL,
                            next_version: next_version,
                            stage_tags: 'hw,medium,provider',
                            default_tags: startedByTimer() ? 'pr daily_regression' : 'pr',
                            default_nvme: 'auto',
                            provider: cachedCommitPragma('Test-provider-tcp', 'ofi+tcp'),
                            run_if_pr: false,
                            run_if_landing: false,
                            job_status: job_status_internal
                        ),

With this definition it would only run if the commit message contained Skip-func-hw-test-medium-tcp-provider: false

[mchaarawi]

That stage is only defined in the https://build.hpdd.intel.com/job/daos-stack/job/daos/job/provider-testing-tcp branch. In order to run that stage with these code changes we need the RPMs built from this PR available in artifactory so we can specify them in the CI_RPM_TEST_VERSION build parameter.

that sounds pretty complicated TBH. We should have a simple option to just add a pragma to run any tests with any provider (which sounds like we do for one medium stage, but not the other which runs daos_test). anyway let's land this PR for now, even though it's missing results for daos_test with the tcp provider.