libfabric: update code owner list

[fengjica]

What?

Update libfabric backend's code owner list.

Summary by CodeRabbit

• Chores
  • Updated code ownership assignments for Libfabric-related paths.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[github-actions]

👋 Hi fengjica! Thank you for contributing to ai-dynamo/nixl.

Your PR reviewers will review your contribution then trigger the CI to test your changes.

🚀

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: fa4742e0-6232-4203-b4c1-e0ab8baa8d9c

📥 Commits

Reviewing files that changed from the base of the PR and between 6a8b0c9 and 727b6e3.

📒 Files selected for processing (1)

• CODEOWNERS

---

📝 Walkthrough

Walkthrough

Updated CODEOWNERS entries for Libfabric paths by replacing one owner while retaining the other listed owners.

Changes

Libfabric ownership

Layer / File(s)	Summary
Update Libfabric owners CODEOWNERS	Three Libfabric-related path entries replace yexiang-aws with oa-aws; existing owners remain listed.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Suggested reviewers: brminich, rakhmets

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description only fills the What section and omits the required Why detail from the template.	Add a Why section with the reason or issue reference, and include How only if there are notable implementation details.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the libfabric code owner list update.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[ovidiusm]

/build

[ovidiusm]

/ok to test 6a8b0c9

[svc-nixl]

🤖 CI Triage Agent — nixl-ci-dl-gpu · commit 827ecfeb

TL;DR: The "Compiling NIXL Docker Image for DL" stage failed because PR_IMAGE interpolated to the invalid tag nixl-ci-dl-gpu-test-:1468 — the ${ucx_version} matrix variable expanded to empty inside the step's run: script, leaving a dangling - before the : tag. Fix the variable expansion so ucx_version is passed into the step (or guard against empty), producing e.g. nixl-ci-dl-gpu-test-master:1468.

Full analysis

Summary: Podman build aborted with Error: tag ...nixl-ci-dl-gpu-test-:1468: invalid reference format in both parallel build_helper_dl matrix branches.

Root cause: In .ci/jenkins/lib/test-dl-matrix.yaml, the "Compiling NIXL Docker Image for DL" step builds PR_IMAGE=...nixl-ci-dl-gpu-test-${ucx_version}:${BUILD_NUMBER}, but ${ucx_version} resolved to an empty string at step-run time (the same emptiness appears in --build-arg UCX_VERSION=). That yields nixl-ci-dl-gpu-test-:1468, where the trailing - immediately before : is not a valid Docker/OCI image reference, so podman build --tag rejects it with exit code 125. The stage-name interpolation (ucx-master, ucx-v1.22.x) works because it's built from the matrix axis, but the axis value is not being substituted into the run: shell script.

Implicated commit: Most likely [REDACTED:Hex High Entropy String] "CI: rename container images (#1839)" by yaroslavs (introduced the nixl-ci-dl-gpu-test-${ucx_version} naming); the modified matrix file .ci/jenkins/lib/test-dl-matrix.yaml is in this PR's diff against origin/main.

File: .ci/jenkins/lib/test-dl-matrix.yaml — the Compiling NIXL Docker Image for DL step, export PR_IMAGE=...nixl-ci-dl-gpu-test-${ucx_version}:${BUILD_NUMBER} line (and the --build-arg UCX_VERSION=${ucx_version} line).

Suggested fix: Ensure ucx_version is available as an environment variable inside the step's run: block. Either expose the matrix axis to the shell (e.g. export ucx_version=${ucx_version} at step scope / add it to the step env:), or reference the correct variable name the matrix runner injects. As a defensive guard, fail fast if empty, e.g.:

: "${ucx_version:?ucx_version is empty — matrix axis not propagated}"
export PR_IMAGE=${registry_host}${registry_path}/pr/${arch}/nixl-ci-dl-gpu-test-${ucx_version}:${BUILD_NUMBER}

Verify the resulting tag is nixl-ci-dl-gpu-test-master:1468 / nixl-ci-dl-gpu-test-v1.22.x:1468 before podman build.

Related: PR #1839 (#1839 — "CI: rename container images"); current PR #1935.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id 5418aea1-21e4-46cd-90a5-88a21ff2c214 in the triage console for the audit trail.

[svc-nixl]

🤖 CI Triage Agent — nixl-ci-dl-gpu-ep · commit 827ecfeb

TL;DR: The Compiling NIXL EP Docker Image for DL stage failed because the podman --tag was nixl-ci-dl-gpu-ep-test-:286 — ${ucx_version} expanded to empty, yielding an "invalid reference format". Fix the PR_IMAGE construction so the tag can't collapse to a dangling -: (and ensure the ucx_version axis is passed into the step's shell env).

Full analysis

Summary: All Compiling NIXL EP Docker Image for DL matrix stages (and their dependent Allocate/Run stages) failed with podman build ... Error: tag ...nixl-ci-dl-gpu-ep-test-:286: invalid reference format, exit code 125.

Root cause: In .ci/jenkins/lib/test-dl-ep-matrix.yaml line 108 the image tag is built as nixl-ci-dl-gpu-ep-test-${ucx_version}:${BUILD_NUMBER}. At execution ${ucx_version} was empty (the log shows nixl-ci-dl-gpu-ep-test-:286 for the tag and a bare --build-arg UCX_VERSION= on line 111), producing an image reference ending in -: which podman rejects. Even though the matrix declares ucx_version: [master, v1.22.x] and the stage names render ucx-master/ucx-v1.22.x correctly, the axis variable did not reach the step's run: shell — a variable-substitution/export problem in the step environment, not the axis labels. PR #1935 (libfabric code-owner list) is unrelated to this pipeline, so this is a pre-existing CI infrastructure failure.

Implicated commit: unknown for the empty-expansion regression itself; the affected line was last meaningfully touched around 55bcf4dcfd9f (lishapira, "ci: Add nixl ep to new dl ci pipeline", #1802). Not caused by PR #1935's commit [REDACTED:Hex High Entropy String].

File: .ci/jenkins/lib/test-dl-ep-matrix.yaml:108 (also mirrored at line 154 in the Run DL EP elastic tests step).

Suggested fix: Ensure the ucx_version matrix axis is exported into the step shell environment before line 108 runs (the harness populates it for taskName but not the run: block). As a defensive measure, fail fast on an empty value and/or reorder the tag so the version isn't adjacent to the : — e.g.:

: "${ucx_version:?ucx_version axis not set}"
export PR_IMAGE=${registry_host}${registry_path}/pr/${arch}/nixl-ci-dl-gpu-ep-test-ucx-${ucx_version}:${BUILD_NUMBER}

and apply the same test-ucx-${ucx_version} form on line 154 so the build and run steps reference the same tag. Confirm with the CI/DevOps owner how axis vars are injected into run: blocks, since the empty expansion is the underlying harness bug.

Related: PR #1802 (introduced this EP pipeline matrix); PR #1935 is the trigger PR but is unrelated to the failure.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id dac591ac-5083-44f3-9179-91447380dcad in the triage console for the audit trail.

[svc-nixl]

🤖 CI Triage Agent — nixl-ci-gpu · commit 827ecfeb

TL;DR: The Docker build failed with Error: tag ...nixl-ci-gpu-test-:2721: invalid reference format because the image tag is constructed from a variable (UCX version / image variant) that resolved to an empty string, producing a malformed nixl-ci-gpu-test-:2721 reference (note the trailing - right before : and the empty --build-arg UCX_VERSION=).

Full analysis

Summary: "Compiling NIXL Docker Image" stage failed (podman build exit 125) on both the ucx-master and ucx-v1.22.x matrix legs due to an invalid image tag reference.

Root cause: PR_IMAGE is built as .../ci/pr/x86_64/nixl-ci-gpu-test-<VARIANT>:2721, but the <VARIANT> component (which mirrors the UCX version / build variant — the same value passed as --build-arg UCX_VERSION=, also empty in the log) expanded to an empty string. The result nixl-ci-gpu-test-:2721 has an empty tag segment before :, which podman rejects as an "invalid reference format." This is a CI-config/variable-interpolation bug, not a code or product defect — the same empty value shows up in two places in the exact command.

Implicated commit: Most likely [REDACTED:Hex High Entropy String] (yaroslavs, "CI: rename container images", PR #1839), which reworked container image naming; possibly interacting with [REDACTED:Hex High Entropy String] (Mikhail Brinskiy, "build: bump UCX version to v1.22.x", PR #1868) which changed the UCX version variable feeding the tag. Cannot pin the exact line — the tools could not locate the pipeline definition file.

File: unknown — the Jenkins pipeline/JJB definition that exports PR_IMAGE and passes --build-arg UCX_VERSION (under .ci/jenkins/); not readable via available tools.

Suggested fix: In the pipeline definition, ensure the image-variant / UCX-version variable is populated before building PR_IMAGE. Either (a) supply a default so the tag component is never empty, or (b) fail fast with a clear message if it's unset. Concretely, guard the tag construction, e.g. PR_IMAGE="...nixl-ci-gpu-test-${UCX_VARIANT:?UCX variant not set}:${BUILD_NUMBER}", and pass a non-empty --build-arg UCX_VERSION=${UCX_VERSION:-v1.22.x}. Review PR #1839's image-naming template against the matrix variable names introduced by PR #1868.

Related: PR #1839 (CI: rename container images), PR #1868 (bump UCX to v1.22.x); triggering PR #1935.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id cba9ed19-0fb5-4529-9fae-18d0ca1fdd8b in the triage console for the audit trail.

[Alexey-Rivkin]

/build

[fengjica]

@ovidiusm @Alexey-Rivkin Just updated it to include one more owner. Could you please trigger the build and test again? Thanks!

[Alexey-Rivkin]

/build

[svc-nixl]

🤖 CI Triage Agent — nixl-ci-dl-gpu-ep · commit b06c3975

TL;DR: The build failed in the "Allocate DL EP Environment" stage because a Slurm salloc on the gb200nvl72_cx8 GB200 partition could not obtain a node within its 3600s --immediate window and errored with "Unable to allocate resources: Connection timed out." This is a cluster resource-availability issue, not a code defect — retry the job or wait for GB200 capacity to free up.

Full analysis

Summary: Stage "Allocate DL EP Environment" (node 224) failed after the Slurm allocation request timed out waiting for a GB200 node.

Root cause: The salloc -N 1 -p gb200nvl72_cx8 --immediate=3600 ... request started at 20:16:57 and, after ~60 minutes of no output (the exact --immediate=3600 window), returned salloc: Pending job allocation 1554351 ... queued and waiting for resources followed by salloc: error: Unable to allocate resources: Connection timed out, and the script exited 1. The GB200 partition had no free node within the immediate window — a scheduling/capacity problem, not a hang in NIXL code. The NIXL EP Docker image built and pushed cleanly in the preceding stage, confirming the PR's code is fine. (The other failure, node 124 ucx-master, is a non-blocking parallel matrix branch that was retried and succeeded in node 142.)

Implicated commit: unknown (not a code regression; [REDACTED:Hex High Entropy String] is not implicated)

File: N/A — failure is in CI infrastructure (Slurm allocation), see stage 224 log line at 21:17:05 salloc: error: Unable to allocate resources: Connection timed out

Suggested fix: Re-run the build to re-queue the Slurm allocation once GB200 (gb200nvl72_cx8) capacity is available. If this recurs frequently, consider (a) raising --immediate beyond 3600s or removing --immediate so the job waits in queue rather than erroring, and/or (b) adding an automatic retry around the slurm.allocation step for transient "Unable to allocate resources"/"Connection timed out" errors so a full green Docker build isn't discarded. This is not a wall-clock-limit bug inside a test; do not treat it as a code hang.

Related: none found.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id 20cbe007-24e3-4b5f-b57b-bffa35baa6a3 in the triage console for the audit trail.