feat(llm-api-gateway): expose GET /info endpoint - #710
Conversation
Signed-off-by: priyaselvaganesan <pselvaganesa@nvidia.com>
📝 WalkthroughWalkthroughThe gateway adds a version-backed ChangesGateway info endpoint
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/invocation-plane-services/llm-api-gateway/go.mod`:
- Around line 24-33: Update the stable OpenTelemetry exporter dependencies in
go.mod from v1.42.0 to v1.44.0, including the OTLP metric, OTLP trace HTTP/gRPC,
stdout trace, and indirect otlptrace modules. Then run go mod tidy to
synchronize go.mod and go.sum.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: e8a760dd-5b51-4f2e-b40f-ebb66e6c9d49
⛔ Files ignored due to path filters (1)
src/invocation-plane-services/llm-api-gateway/go.sumis excluded by!**/*.sum
📒 Files selected for processing (5)
src/invocation-plane-services/llm-api-gateway/api/BUILD.bazelsrc/invocation-plane-services/llm-api-gateway/api/info_test.gosrc/invocation-plane-services/llm-api-gateway/api/routes.gosrc/invocation-plane-services/llm-api-gateway/cmd/llm-api-gateway/BUILD.bazelsrc/invocation-plane-services/llm-api-gateway/go.mod
| go.opentelemetry.io/otel v1.44.0 | ||
| go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.42.0 | ||
| go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.42.0 | ||
| go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.42.0 | ||
| go.opentelemetry.io/otel/exporters/prometheus v0.64.0 | ||
| go.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.42.0 | ||
| go.opentelemetry.io/otel/metric v1.42.0 | ||
| go.opentelemetry.io/otel/sdk v1.42.0 | ||
| go.opentelemetry.io/otel/sdk/metric v1.42.0 | ||
| go.opentelemetry.io/otel/trace v1.42.0 | ||
| go.opentelemetry.io/otel/metric v1.44.0 | ||
| go.opentelemetry.io/otel/sdk v1.44.0 | ||
| go.opentelemetry.io/otel/sdk/metric v1.44.0 | ||
| go.opentelemetry.io/otel/trace v1.44.0 |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
According to official OpenTelemetry Go documentation for v1.44.0, are OTLP exporter modules at v1.42.0 supported with go.opentelemetry.io/otel, metric, sdk, and trace modules at v1.44.0?
💡 Result:
The OpenTelemetry Go project does not explicitly define or document support for mixing different versions of its modules within the same application [1][2]. According to its versioning policy, OpenTelemetry-Go follows Go's idiomatic module versioning [1], which generally assumes that dependencies should be kept synchronized across related modules to ensure expected behavior and compatibility [3]. In practice, the OpenTelemetry-Go repository releases its core stable modules (such as go.opentelemetry.io/otel, go.opentelemetry.io/otel/sdk, and the various OTLP exporters) as a set with matching version numbers [3][4][5]. While the Go module system allows for version mismatches in some cases if APIs remain compatible, OpenTelemetry's own release notes and repository structure strongly imply that stable modules are intended to be used at the same version [3][4]. Mixing a v1.42.0 exporter with v1.44.0 core modules is not officially supported or recommended, as newer features—such as those introduced in v1.44.0—may rely on APIs or behaviors not present or fully matched in the older v1.42.0 exporter code [6]. To ensure stability and access to the latest features and fixes, it is recommended that you update your OTLP exporter modules to match the version of your core OpenTelemetry modules (v1.44.0) [3].
Citations:
- 1: https://github.com/open-telemetry/opentelemetry-go/blob/main/VERSIONING.md
- 2: Document our compatibility promise open-telemetry/opentelemetry-go#6274
- 3: https://opentelemetry.io/docs/specs/otel/versioning-and-stability/
- 4: https://github.com/open-telemetry/opentelemetry-go/releases
- 5: https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlptrace
- 6: https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.44.0
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- guidance files ---'
find .. -name AGENTS.md -print
printf '%s\n' '--- module files ---'
cat -n src/invocation-plane-services/llm-api-gateway/go.mod
printf '%s\n' '--- relevant checksums ---'
rg -n 'go\.opentelemetry\.io/(otel|otel/exporters/otlp)' src/invocation-plane-services/llm-api-gateway/go.sum 2>/dev/null || true
printf '%s\n' '--- repository state ---'
git status --short
printf '%s\n' '--- available Go tooling ---'
go version 2>&1 || trueRepository: NVIDIA/nvcf
Length of output: 14040
🏁 Script executed:
#!/bin/bash
set -u
printf '%s\n' '--- repository guidance ---'
cat -n AGENTS.md 2>/dev/null || true
printf '%s\n' '--- llm-api-gateway guidance ---'
cat -n src/invocation-plane-services/llm-api-gateway/AGENTS.md 2>/dev/null || true
printf '%s\n' '--- tidy diff (offline, non-mutating) ---'
cd src/invocation-plane-services/llm-api-gateway
GOTOOLCHAIN=local GOPROXY=off go mod tidy -diff 2>&1
tidy_status=$?
printf 'tidy_status=%s\n' "$tidy_status"
printf '%s\n' '--- cached OpenTelemetry module requirements ---'
for f in \
"$OLDPWD/../../go/pkg/mod/go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc@v1.42.0/go.mod" \
"$OLDPWD/../../go/pkg/mod/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc@v1.42.0/go.mod" \
"$OLDPWD/../../go/pkg/mod/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp@v1.42.0/go.mod" \
"$OLDPWD/../../go/pkg/mod/go.opentelemetry.io/otel/exporters/stdout/stdouttrace@v1.42.0/go.mod"; do
if [ -f "$f" ]; then
printf '\n--- %s ---\n' "$f"
sed -n '1,80p' "$f"
else
printf 'missing: %s\n' "$f"
fi
done
exit 0Repository: NVIDIA/nvcf
Length of output: 28045
🏁 Script executed:
#!/bin/bash
set -u
printf '%s\n' '--- repository guidance ---'
cat -n AGENTS.md 2>/dev/null || true
printf '%s\n' '--- llm-api-gateway guidance ---'
cat -n src/invocation-plane-services/llm-api-gateway/AGENTS.md 2>/dev/null || true
printf '%s\n' '--- tidy diff (offline, non-mutating) ---'
cd src/invocation-plane-services/llm-api-gateway
GOTOOLCHAIN=local GOPROXY=off go mod tidy -diff 2>&1
tidy_status=$?
printf 'tidy_status=%s\n' "$tidy_status"
printf '%s\n' '--- cached OpenTelemetry module requirements ---'
modcache="$(go env GOPATH)/pkg/mod"
for f in \
"$modcache/go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc@v1.42.0/go.mod" \
"$modcache/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc@v1.42.0/go.mod" \
"$modcache/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp@v1.42.0/go.mod" \
"$modcache/go.opentelemetry.io/otel/exporters/stdout/stdouttrace@v1.42.0/go.mod"; do
if [ -f "$f" ]; then
printf '\n--- %s ---\n' "$f"
sed -n '1,80p' "$f"
else
printf 'missing: %s\n' "$f"
fi
done
exit 0Repository: NVIDIA/nvcf
Length of output: 33914
🌐 Web query:
site:github.com/open-telemetry/opentelemetry-go VERSIONING.md module versions independently versioned stable v1.44.0 exporters
💡 Result:
In the OpenTelemetry Go project, modules are versioned based on their stability status as defined in the project's VERSIONING.md [1][2]. While stable modules—which guarantee a stable public API and telemetry—are often released as part of a coordinated set (such as the v1.44.0 release) [3][4][5], the project architecture supports independent versioning for experimental modules [6][2]. Key points regarding the versioning policy: * Stable vs. Experimental Stability: Experimental modules are versioned starting at v0.0.0, allowing for breaking changes [1][2]. Mature modules that provide stable guarantees are versioned with a major version greater than v0 [2]. * Coordinated Releases: To maintain usability, stable modules within the same major version series typically use the same entire version number (e.g., v1.44.0) during project-wide releases [4][2]. For instance, the v1.44.0 release included coordinated versions for multiple modules, such as v1.44.0, v0.66.0, and v0.20.0 [3][7]. * Module Encapsulation: Modules are used to encapsulate distinct components like instrumentation, detectors, and exporters [1][2]. This structure allows the project to evolve different parts of the library at different rates while maintaining stability for production-grade components [1][6]. * Recent Practice: While releases are often published as a group to ensure compatibility, recent discussions and practices have moved toward more explicit module-specific release notes to improve clarity, even when published under a coordinated repository-level version [4]. In summary, while stable exporters are generally kept in alignment with the core stable release (such as v1.44.0) to simplify dependency management and ensure compatibility, the underlying versioning policy explicitly permits and facilitates independent versioning for experimental components [1][4][6].
Citations:
- 1: https://github.com/open-telemetry/opentelemetry-go/blob/main/VERSIONING.md
- 2: https://github.com/open-telemetry/opentelemetry-go/blob/v1.40.0/VERSIONING.md
- 3: https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.44.0
- 4: Improve GitHub release notes by publishing module-specific releases open-telemetry/opentelemetry-go#8414
- 5: Release 1.44.0 open-telemetry/opentelemetry-go#8376
- 6: Module version policy compliance and release tooling improvement open-telemetry/opentelemetry-go#1446
- 7: https://github.com/open-telemetry/opentelemetry-go/releases
🌐 Web query:
site:opentelemetry.io/docs/languages/go versioning modules exporter core same version
💡 Result:
In modular software architecture, including projects like OpenTelemetry, modules and core components do not strictly require the same version number. Versioning strategies are typically determined by the release lifecycle, dependency compatibility, and stability guarantees of the specific components rather than a forced lock-step with a core package [1]. For example, within the OpenTelemetry Go ecosystem, while the core API and SDK components are often released and tracked together, individual exporters and instrumentation libraries may follow their own release cycles or versioning schemes depending on their stability status (e.g., stable, beta) and maintenance cadence [2][1]. Best practices for versioning modules in such systems include: 1. Independent Versioning: If modules are functionally decoupled from the core, they can be versioned independently to allow for faster updates or bug fixes without requiring a full system-wide version bump. 2. Semantic Versioning (SemVer): Use SemVer to signal the nature of changes (major, minor, patch). This allows users to understand the impact of upgrading a specific module without needing the core version to match [1]. 3. Compatibility Guarantees: If you choose to use independent versioning, maintain clear documentation regarding compatibility between module versions and core versions. 4. Lock-step Versioning: Only adopt this if the modules are tightly coupled, have shared internal dependencies that break frequently, or if your deployment strategy specifically requires uniform versions across the entire stack to simplify configuration and testing. In summary, matching versions is often unnecessary and can be counterproductive if it forces unnecessary releases. Prioritize independent, semantic versioning to provide flexibility and clarity to your users [1].
Citations:
🏁 Script executed:
#!/bin/bash
set -u
modcache="$(go env GOPATH)/pkg/mod"
printf '%s\n' '--- OpenTelemetry versioning policy ---'
for f in \
"$modcache/go.opentelemetry.io/otel@v1.44.0/VERSIONING.md" \
"$modcache/go.opentelemetry.io/otel@v1.44.0/README.md"; do
if [ -f "$f" ]; then
printf '\n--- %s ---\n' "$f"
rg -n -i -C 3 'version|module|compatib|release|stable|export' "$f" | head -240
else
printf 'missing: %s\n' "$f"
fi
done
printf '%s\n' '--- cached v1.44.0 core module metadata ---'
for f in \
"$modcache/go.opentelemetry.io/otel@v1.44.0/go.mod" \
"$modcache/go.opentelemetry.io/otel/metric@v1.44.0/go.mod" \
"$modcache/go.opentelemetry.io/otel/sdk@v1.44.0/go.mod" \
"$modcache/go.opentelemetry.io/otel/sdk/metric@v1.44.0/go.mod" \
"$modcache/go.opentelemetry.io/otel/trace@v1.44.0/go.mod"; do
if [ -f "$f" ]; then
printf '\n--- %s ---\n' "$f"
sed -n '1,70p' "$f"
else
printf 'missing: %s\n' "$f"
fi
done
printf '%s\n' '--- module graph (offline) ---'
cd src/invocation-plane-services/llm-api-gateway
GOTOOLCHAIN=local GOPROXY=off go mod graph 2>&1 | rg 'go\.opentelemetry\.io/(otel|proto)' | head -160
printf 'graph_status=%s\n' "${PIPESTATUS[0]}"Repository: NVIDIA/nvcf
Length of output: 19027
Align the stable OpenTelemetry modules to v1.44.0.
OpenTelemetry Go requires stable modules to use the same full version. Update the v1.42.0 OTLP and stdout exporters, including the indirect otlptrace module, to v1.44.0 and run go mod tidy.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/invocation-plane-services/llm-api-gateway/go.mod` around lines 24 - 33,
Update the stable OpenTelemetry exporter dependencies in go.mod from v1.42.0 to
v1.44.0, including the OTLP metric, OTLP trace HTTP/gRPC, stdout trace, and
indirect otlptrace modules. Then run go mod tidy to synchronize go.mod and
go.sum.
1 participant
Why
DGXC Ops and QA need a reliable way to identify the exact build of each deployed NVCF service. This adds a GET /info endpoint to llm-api-gateway returning service name, semver, and commit SHA stamped at build time.
What changed
echo.WrapHandler(golibversion.Handler()), so it runs through echo's existing middleware stack.Additional Details
/info returns:
service, version, and commit are injected via Bazel x_defs at build time. Unknown fallbacks apply for unstamped builds.
Customer Release Notes
Not customer visible.
Plan Summary
Not applicable.
Usage
Not applicable.
Testing
Built a stamped image from the repo root with
bazel build //src/invocation-plane-services/llm-api-gateway/cmd/llm-api-gateway:image.tar --stampand verified the binary embeds the expected service name, version, and full commit SHA. Unit tests pass withgo test ./....Notes
This is one of several Phase 1 Go service /info PRs. Pattern follows merged go-lib handler (#270), helm-reval (#275), and grpc-proxy (#610). Each service PR is independent.
References
POR: https://docs.google.com/document/d/1XigTpFIMVfkR-RgwdF7urquq8YxGYDEVamsrJNJwC-U
Issues
Relates to #315
Related Pull Requests
GET /infoendpoint #275 (helm-reval, merged)Dependencies
Bumps go-lib from v0.0.0-20260513170923-714a7c905aa0 to v0.0.0-20260728185909-afca4ec2fb26 (Apache-2.0). Go MVS pulls otel 1.43->1.44 and related golang.org/x deps forward as go-lib requires.
Summary by CodeRabbit
New Features
/infoendpoint to report the API gateway’s service version and Git commit information.Tests