[WIP] refactor datastore struct

[nirrozenbaum]

instead added ctx to one function that required it which is more aligned with best practices.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: nirrozenbaum
Once this PR has been reviewed and has the lgtm label, please assign sergeykanzhelev for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[netlify]

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

Name	Link
🔨 Latest commit	4bb3be3
🔍 Latest deploy log	https://app.netlify.com/sites/gateway-api-inference-extension/deploys/67ed2bdb531509000887d092
😎 Deploy Preview	https://deploy-preview-641--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 site configuration.

[ahg-g]

The existing logic is intentional. We need the parent context because it is used to start a metrics probing goroutine that should continue to live beyond the life of the reconcile event that triggered its creation.

/hold

[nirrozenbaum]

can you point me to the code you’re referring to?
reconcile event also gets context (in controller-runtime) and that can be used in a new go routine.
in general, best practice for context usage is to usually propagate the context between functions rather than saving in struct.

[ahg-g]

My point is that the context that is created as part of the pod reconcile even is short lived, its lifespan is related to that of the event. The metrics probing thread on the other hand is supposed to live longer than the pod reconcile event that triggered the creation of the metrics probing thread.

[nirrozenbaum]

My point is that the context that is created as part of the pod reconcile even is short lived, it is live span is related to that of the event.

I agree. I was looking to see the specific code you're referring to in order to make sure I'm not missing something.

The metrics probing thread on the other hand is supposed to live longer than the pod reconcile event that triggered the creation of the metrics probing thread.

as far as I know, it's not recommended to store context in a struct. there are other ways in go to do what you're describing here. for example, datastore may use a stop channel and upon receiving a signal on that channel stop all its go routines (that are managed by the datastore struct, each may have a context that can be cancelled or a stop channel).
we can also use sync.WaitGroup to wait until all routines are stopped (internally in the datastore).

bottom line, best practices recommend not to save context in a struct but to propagate it in function calls. for the use case described above I think stop channel fits more.

if the above sounds reasonable to you, I can implement it, LMKWYT.

[ahg-g]

Sounds good, @liu-cong perhaps can help review your proposal.

[liu-cong]

@nirrozenbaum , yeah a stop channel sounds good to me. The key code path is line #239 in datastore.go: pm = ds.pmf.NewPodMetrics(ds.parentCtx, pod, ds), which creates a new PodMetrics object which behind the scenes starts a goroutine to refresh metrics. We need to make sure the goroutine is gracefully handled when receiving the SIGINT or SIGTERM (this is how the parentCtx is used today).

I can review it once you refactor this. Thanks!

[liu-cong]

/assign

[kfswain]

if the above sounds reasonable to you, I can implement it, LMKWYT.

+1 sounds great

[k8s-ci-robot]

PR needs rebase.

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.

[kfswain]

are we going to use this PR for the restructuring?

[nirrozenbaum]

main changed a lot and I'm busy in this cycle with other PRs, will create a new PR probably early next week.
can be closed for now.