feat: make prefix of endpoints configurable

[AyushSawant18588]

Description
Introduces configurable provider endpoint prefixes via global configurations.

Compatibility
Non-breaking: defaults preserve current behavior for OpenAI (/), Cohere (/cohere), Anthropic (/anthropic) if not set.

Related Issues/PRs (if applicable)
#1457

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.98%. Comparing base (ad5f75e) to head (1a6240b).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1514      +/-   ##
==========================================
+ Coverage   83.92%   83.98%   +0.05%     
==========================================
  Files         144      144              
  Lines       12668    12705      +37     
==========================================
+ Hits        10632    10670      +38     
+ Misses       1421     1419       -2     
- Partials      615      616       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[siddharth1036]

@AyushSawant18588 can you check if e2e tests are required with custom prefixes?

[mathetake]

i would rather have an explicit exhaustive list here to avoid manual validation at runtime

Suggested change

	# Comma-separated key-value pairs for endpoint prefixes.
	# Format: "openaiPrefix:/prefix1,anthropicPrefix:/prefix2"
	# Example: "openaiPrefix:/,coherePrefix:/cohere,anthropicPrefix:/anthropic"
	endpointPrefixes: ""
	openai: ""
	anthropic: "/anthropic"
	cohere: "/cohere"

[mathetake]

also could you add detailed comments here by showing exact paths examples. At least one for each provider

[AyushSawant18588]

The idea behind using key-value pairs for endpoint prefixes was to make the design more scalable. As we add support for more providers in the future, maintaining an explicit list would require updating multiple files (helm values, controller deployment, controller, extproc, gateway_mutator, internalapi, etc.) each time. With the current approach, any new provider addition would only require changes within the EndpointPrefixes struct and related functions in the internalapi package.
What are your thoughts on this trade-off?

[mathetake]

I would prefer my suggestion for now, not trying to solve non existing problem

[mathetake]

btw you can concatenate strings in helm functions so your concern on multiple changes doesn't apply here i believe

[mathetake]

my suggestion is "let's not expose the error prone string format to users". I am not saying we shouldn't use the concatenated ones in arguments in extproc/controller, it should be totally fine

[AyushSawant18588]

Oh thanks, got your point so expose explicit prefixes via values but concatenate and pass it as a string in endpointPrefixes arg to controller. So this structure is fine for string after concatenation right?

--endpointPrefixes='endpointConfig.endpointPrefixes=openaiPrefix:/,coherePrefix:/cohere,anthropicPrefix:/anthropic'

[mathetake]

yes

[mathetake]

For e2e you can reuse the existing e2e-namespaced for non default config https://github.com/envoyproxy/ai-gateway/tree/main/tests/e2e-namespaced @AyushSawant18588

[AyushSawant18588]

For e2e you can reuse the existing e2e-namespaced for non default config https://github.com/envoyproxy/ai-gateway/tree/main/tests/e2e-namespaced @AyushSawant18588

can you tell what e2e test are you suggesting to add?

[mathetake]

i would say pass your new helm value with non-default prefix for openai in the e2e setup, and then access the gateway