feat(stack): surface apiKeys/sis/reval gateway-route enable flags

[sparve-nv]

Summary

Surface the apiKeys, sis, and reval gateway-route enable flags in the self-managed stack so they can be toggled from environments/<env>.yaml, instead of only by patching global.yaml.gotmpl. Each flag defaults to true (the chart default), so existing deployments are unchanged.

Additional Details

global.yaml.gotmpl's nvcfGatewayRoutes.routes block already passes the enable flags through from ingress.gatewayApi.routes.* for nats, ess, nvcfApi.grpc, nvctApi.grpc, and grpcWorker, but for apiKeys it emitted only routeAnnotations and did not emit sis / reval at all. The ingress release reads only global.yaml.gotmpl, so ingress.gatewayApi.routes.{apiKeys,sis,reval}.enabled set in an environment file never reached the release — the only way to disable those routes was a carried patch to global.yaml.gotmpl.

The nvcf-gateway-routes chart already gates all three via nvcfGatewayRoutes.routes.{apiKeys,sis,reval}.enabled (default true); this change only adds the missing stack passthrough. No chart change.

• deploy/stacks/self-managed/global.yaml.gotmpl — add enabled dig passthroughs (default true) for apiKeys / sis / reval, alongside their existing routeAnnotations.
• deploy/stacks/self-managed/environments/base.yaml — document the three flags (enabled: true) under ingress.gatewayApi.routes.

Example — keep api-keys off the public edge and drop the unused sis/reval routes:

# environments/<env>.yaml
ingress:
  gatewayApi:
    routes:
      apiKeys: { enabled: false }
      sis:     { enabled: false }
      reval:   { enabled: false }

For the Reviewer

• Backward-compatible: each flag dig-defaults to true, matching the chart default, so an unset flag renders identically.
• This is the same default-preserving mechanism the stack already uses for the other surfaced routes and for api.accountBootstrap.enabled (Allow disabling the NVCF API account-bootstrap post-install hook in the nvcf-api chart #894 / feat(nvcf-api): add api.accountBootstrap.enabled flag to gate account-bootstrap hook #895): add the knob, default to current behavior, let operators opt out.

For QA

Automated test (make test). Added deploy/stacks/self-managed/tests/gateway-routes-enable-wiring.sh, wired into the offline make test target next to gateway-routes-local-chart.sh. It follows the existing value-wiring pattern (pdb-value-wiring.sh): it renders the ingress release values with helmfile write-values and asserts, via yq, that nvcfGatewayRoutes.routes.{apiKeys,sis,reval}.enabled is true by default and false when the environment file sets ingress.gatewayApi.routes.{apiKeys,sis,reval}.enabled: false. As a teeth-check, reverting only global.yaml.gotmpl to main (keeping the base.yaml docs) makes the test fail (expected enabled=true), confirming it guards the passthrough and that base.yaml alone is inert without it.

Manual render. Also rendered the ingress release with helmfile template -l name=ingress (helmfile v1.7.4) against the local nvcf-gateway-routes chart, using a minimal env file that supplies the operator-required gateway names.

• Case A — default (flags unset): api-keys, sis, and reval HTTPRoutes all render, alongside nvcf-api, nvct-api, invocation-service, llm-api-gateway, and the grpc TCPRoute. A diff of this render against the same render on origin/main (before the change) is empty — byte-identical, confirming no behavior change when the flags are unset.
• Case B — override (ingress.gatewayApi.routes.{apiKeys,sis,reval}.enabled=false): the api-keys, sis, and reval HTTPRoutes are absent; every other route still renders.

Issues

Fixes #1374

Checklist

• I am familiar with the Contributing Guidelines.
• I have signed off my commits for DCO compliance.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

Summary by CodeRabbit

• New Features

  • Gateway routes for API keys, SIS, and revalidation remain enabled by default.
  • Each route can be disabled independently through explicit environment configuration.
  • Route annotations remain configurable across deployment environments.
  • NATS services now advertise shared and region-specific server tags, with invocation routing scoped to the NCP region.

• Tests

  • Added integration coverage confirming default route enablement and explicit disablement behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 6d0596b5-3ba5-4c73-9054-3a3538fcb23a

📥 Commits

Reviewing files that changed from the base of the PR and between d577db5 and 9c0da39.

📒 Files selected for processing (3)

• deploy/stacks/self-managed/Makefile
• deploy/stacks/self-managed/environments/base.yaml
• deploy/stacks/self-managed/global.yaml.gotmpl

Included review availability: Your plan provides up to 12 included reviews per hour; 10 remain after this review.

---

📝 Walkthrough

Walkthrough

The self-managed stack omits unset apiKeys, sis, and reval route enable overrides. Explicit false values still disable routes. An integration test validates both behaviors.

Changes

Gateway route flags

Layer / File(s)	Summary
Conditionally forward route enable flags deploy/stacks/self-managed/environments/base.yaml, deploy/stacks/self-managed/global.yaml.gotmpl	The base configuration no longer sets explicit true values. The global template forwards enabled only when configured and preserves apiKeys route annotations.
Validate rendered route flags deploy/stacks/self-managed/tests/gateway-routes-enable-wiring.sh, deploy/stacks/self-managed/Makefile	The integration test verifies omitted overrides and explicit false values. The Makefile runs the test.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 9c0da

This change exposes existing gateway-route enable flags while preserving current defaults, so existing deployments remain unchanged; no actionable merge-blocking risk remains after normal checks and review.

Suggested reviewers: raitnao

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Out of Scope Changes check	⚠️ Warning	The gateway-route changes are in scope, but base.yaml also changes NATS server tags and invocation subjects from local to regional values. These changes are not covered by issue #1374 or the stated PR…	Remove the unrelated NATS tag and invocation-subject changes, or provide linked requirements that justify them in this pull request.
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 6 functions across 1 files. (3 skipped: 3…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title uses the required Conventional Commits format, includes the required scope for a customer-impacting feat, and accurately describes the gateway-route flag change.
Linked Issues check	✅ Passed	The changes satisfy issue #1374. They surface the apiKeys, sis, and reval enable flags, preserve chart defaults when unset, allow explicit false values, document the options, add wiring coverage, and …

Full details: Linked Issues check

Explanation

The changes satisfy issue #1374. They surface the apiKeys, sis, and reval enable flags, preserve chart defaults when unset, allow explicit false values, document the options, add wiring coverage, and leave the gateway-routes chart unchanged.

Full details: Out of Scope Changes check

Explanation

The gateway-route changes are in scope, but base.yaml also changes NATS server tags and invocation subjects from local to regional values. These changes are not covered by issue #1374 or the stated PR objectives.

Full details: Docstring Coverage

Explanation

Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 6 functions across 1 files. (3 skipped: 3 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[sbaum1994]

Can we keep this default owned by the gateway-routes chart instead of re-declaring true here and in base.yaml? The stack adapter should only forward enabled when the operator explicitly supplies an override.

The broader concern is that copying a downstream default into an integration layer creates two sources of truth. For example, if a future gateway-routes release defaults this route off to address a security or compatibility concern, the self-managed stack would silently force it back on. Please omit or comment out the base values, conditionally emit enabled, and adjust the default test to assert that the stack passes no override. The chart tests can remain responsible for the chart default.

[sparve-nv]

Thanks for suggestion.

Addressed in latest commit (d577db5)
Changes:

• Dropped the true default from both global.yaml.gotmpl and base.yaml. The stack now forwards enabled only when an operator sets it (hasKey guard); otherwise it passes nothing and the gateway-routes chart owns the default.
• Updated the test so the default case asserts no override is passed. Verified with helmfile write-values: unset → chart default stands (existing installs unchanged); enabled: false → forwarded.