Add WG Service Mesh

[keithmattix]

Signed-off-by: Keith Mattix II [email protected]

Full proposal can be found here.

sig-network has agreed to sponsor this working group. If I'm missing anything in the process, please let me know!

Notes for reviewer

• 2 WG chairs are currently awaiting k8s org membership (sponsors have already confirmed) and the other chair is a member of kubernetes-sigs. Please advise on next steps
• Meeting times and links are TBD
• We have yet to be assigned a liason from the Steering Committee

[keithmattix]

/hold

[k8s-ci-robot]

Welcome @keithmattix!

It looks like this is your first PR to kubernetes/community 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/community has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @keithmattix. Thanks for your PR.

I'm waiting for a kubernetes 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.

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/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: keithmattix
To complete the pull request process, please assign nikhita after the PR has been reviewed.
You can assign the PR to them by writing /assign @nikhita in a comment when ready.

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

[keithmattix]

/label committee/steering

[k8s-ci-robot]

@keithmattix: The label(s) /label committee/steering cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor

In response to this:

/label committee/steering

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/test-infra repository.

[MadhavJivrajani]

/ok-to-test
/committee steering

[keithmattix]

/verify-owners

[keithmattix]

/verify-owners

[thockin]

The counter-argument to be considered here is whether this "naturally" falls under the purvey of the existing Gateway sub-project (https://github.com/kubernetes/community/tree/master/sig-network#gateway-api).

My initial feeling is that Gateway should have right of first refusal on the topic?

@bowei
@hbagdi
@robscott
@shaneutt
@youngnick

[robscott]

@thockin Thanks for checking with us! The way this has been described to me is a working group that reports to Gateway API and that makes sense to me. The working group would make proposals to the broader Gateway API community for how mesh could be modeled + any related API changes necessary to enable that approach, but the WG would not directly be able to make API changes. I know there's not really any prior art for a working group within the scope of a subproject, but I think that's effectively what this would be.

@keithmattix @mikemorris @howardjohn Does my understanding of the scope of this WG make sense to you?

[keithmattix]

Yep, that's my understanding as well @robscott

[thockin]

In that case I have no real objections. The main objections came from other Gateway folks.

[howardjohn]

Yes that is my understanding, the goal is effectively to provide a structured grouping of folks working on the same problems (as they are fairly large, to avoid dilution of other Gateway efforts).

[youngnick]

I'm also +1, I think that the Mesh work really needs to be done, but can't be the focus of the main Gateway effort right now, this is a great solution.

[tomkerkhove]

How does this WG relate to the existing open standards such as SMI?

/cc @leecalcote

[k8s-ci-robot]

@tomkerkhove: GitHub didn't allow me to request PR reviews from the following users: leecalcote.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

How does this WG relate to the existing open standards such as SMI?

/cc @leecalcote

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/test-infra repository.

[gyohuangxin]

There is already a similar CNCF working group: CNCF Service Mesh Working Group, can we make some connections between these two WGs?

[craigbox]

How does this WG relate to the existing open standards such as SMI?

Members of the SMI community have been discussing moving to support the Gateway API for some time, and this WG is the proposed place for that to happen. More context is linked in the full proposal doc

There is already a similar CNCF working group: CNCF Service Mesh Working Group, can we make some connections between these two WGs?

There is a TAG Network in CNCF and a SIG Network in Kubernetes; they serve different purposes. A goal of WG Mesh is to propose code changes to the Gateway API, which is a Kubernetes project, therefore we believe that creating a Kubernetes working group is the correct path.

I joined the TAG Network meeting today to discuss the difference between the groups, and we had broad agreement that the scope of WG Service Mesh would be the API and conformance of the implementations, and the scope of TAG Network (and specifically the SMP project) is in measuring performance with what various vendors offer.

[lauralorenz]

Hi, I'd like to suggest that SIG-Multicluster also be represented in some way here (possibly as a stakeholder SIG); in particular, one of its flagship projects, the MCS API, has integrations with some Gateway API and service mesh implementations (GKE, Istio). As an upstream standard intersecting with service meshes, MCS API has similar scope and intent as the suggested purview of this WG. cc @pmorie @JeremyOT @thockin

[thockin]

As discussed at steering this week, we do not need full WG authorization. This is effectively a sub-sub-project and is entirely ours to manage within the existing Gateway effort. Shall we close this?

[keithmattix]

@thockin @lauralorenz
While I'm happy to work directly with the Gateway community, it sounds like Sig Multicluster does perhaps need the cross-SIG WG structure. Shall we add this to the agenda for a future meeting, or does Steering want to see the WG proposal reformulated to include SIG-Multicluster?

[thockin]

We don't NEED a WG charter just to talk to our friends in another SIG.

…

On Fri, Jul 8, 2022 at 3:24 PM Keith Mattix II ***@***.***> wrote: @thockin <https://github.com/thockin> @lauralorenz <https://github.com/lauralorenz> While I'm happy to work directly with the Gateway community, it sounds like Sig Multicluster does perhaps need the cross-SIG WG structure. Shall we add this to the agenda for a future meeting, or does Steering want to see the WG proposal reformulated to include SIG-Multicluster? — Reply to this email directly, view it on GitHub <#6724 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKWAVBTLOE62R4UP7CPVQLVTCTBPANCNFSM52KMX64A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lauralorenz]

FWIW I am 100% out of the loop on any IRL / steering committee discussions. /If/ the WG was going to be the way forward I didn't want SIG-MC to be left out, but if responsibility is staying within the Gateway subproject (and analogously, the MCS API subproject in SIG-MC) that is totally fine. Happy to be friends though :)

[keithmattix]

Sounds like we're all agreed then that the WG isn't needed at this point and that we'll work in the existing subprojects in the interests of simplicity for as long as we can. Thanks all; closing this now.