Datalayer refactoring: HTTP datasource and client

[irar2]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

This PR refactors metrics datasource and client into a general HTTP datasource and client, allowing code reuse in similar scenarios, e.g., gathering of models info.

Which issue(s) this PR fixes:

Does this PR introduce a user-facing change?:

NONE

[netlify]

✅ Deploy Preview for gateway-api-inference-extension ready!

Name	Link
🔨 Latest commit	e997623
🔍 Latest deploy log	https://app.netlify.com/projects/gateway-api-inference-extension/deploys/6963a92d9c3f23000842bc5d
😎 Deploy Preview	https://deploy-preview-2120--gateway-api-inference-extension.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

Hi @irar2. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[elevran]

/ok-to-test

[elevran]

nit: the copyright is realy 2025-... I don't think we need to change copyright statements in files modified in a specific year,

[irar2]

Reverted to 2025

[elevran]

Q: I think there are two high level ways to refactor this:

• keep a shared implementation and configure it from the outside with implementation specific details (the typed-name, parse callback, output type, etc); or
• create specific instances (e.g., metrics, v1/models) that build a data source from lower level building blocks (e.g., they would have their own TypedName, call client.Get() and then pass the result to an internal parse method, instead of adding parse to the Get parameters).

To clarify, you could still have an HTTPDataSource under pkg/epp/datalayer/http, but add MetricsSource and ModelsSource Go files next to it or in their own directories. By embedding an HTTPDataSource the specific sources could reuse the shared implementation.

Out of curiosuity, any thoughts on preferring one over the other? Either approach works, they can be thought of as composition vs inheritance.
I would lean towards the second approach (e.g., there is no HTTPDataSource registered factory in the system, only ones for metrics and v1/models so the HTTP bits seem like an implemntation detail to me and can be modeled as function "building blocks" and not reuse the full struct, esp. since v1/models would be in a different repo altogether).

[irar2]

I think that the second approach allows less code reuse comparing to the first one

[elevran]

/ok-to-test
/lgtm
left a comment regarding reuse approach, just for thought - no need to change implementation if you prefer it the current way.

[shmuelk]

/lgtm

[nirrozenbaum]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: irar2, nirrozenbaum

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [nirrozenbaum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment