Identify owning SIG

[BenTheElder]

Workgroups are temporary time bounded groups, this project should specify the owning sig and be listed as a subproject of one of the SIGs in the metadata in github.com/kubernetes/community, you can identify the workgroup as a place to discuss the project but it cannot be the owner and we should sort that out sooner than later so we don't have confusion when the workgroup winds down.

cc @kubernetes/steering-committee

[SergeyKanzhelev]

sig network or sig autoscaling might be a good home

added as. an agenda item for the wednesday meeting: https://docs.google.com/document/d/1aExJFtaLnO-TM6_2uILgI8NI0IjOm7FcwLABBKEMEo0/edit?tab=t.0#heading=h.zd57bzqasuuz

[ahg-g]

I think sig networking would be the most appropriate

[BenTheElder]

We just need agreement from a SIG to be responsible for hosting the project long term and to setup pointers in sigs.yaml and the README, it sounds like it could be SIG net and that sounds like the closest fit to me personally.

[ahg-g]

@robscott fyi

[aojea]

can you put this in the next sig network agenda? or open an email thread in sig-network mailing list with the request?

[BenTheElder]

FYI kubernetes/community#8056, it was introduced under SIG Apps, actually.

I have a thread with the github management team about preventing this sort of confusion in the future by tweaking the request template to clearly ask for the sponsoring SIG for future repos to be one particular SIG.
In my case I saw the WG serving README PR and this repo's README but not the commit to SIG Apps, and both sigs listed in the request.

If you all are fine with SIG Apps being the sponsoring SIG, then lets just clarify the README here and in the wg-serving README/charter to make it clear that SIG Apps owns it and wg-serving is where it's being discussed.

[terrytangyuan]

cc @shaneutt

[shaneutt]

I think sig networking would be the most appropriate

If you all are fine with SIG Apps being the sponsoring SIG, then lets just clarify the README here

I am open to the suggestion to put this under SIG Network, especially given that it has close ties with Gateway API and deals with application level routing and load-balancing for LLM inference traffic. However given what @BenTheElder is saying, it sounds like we should discuss this at some length. Looking forward to further discussion on this.