[Incubation] kubegateway Incubation Application #1484
Comments
|
As an Individual on the Kubernetes Steering Committee: This name "K8sGateway" seems confusing, as a project not associated with the Kubernetes organization, and overlapping with the upstream Kubernetes Gateway project. |
|
Another Kubernetes Steering member checking in... I'm also curious to know if there was any work done to collaborate with the upstream Gateway API contributors? |
|
Hey, from a CNCF Trademark perspective, we run into this issue quite a bit when projects use a CNCF trademark term in a project, we have guidelines here that we expect everyone to follow: https://www.linuxfoundation.org/legal/trademark-usage A simple fix here would be to call the project "kubegateway" or some variation of that of a term that isn't trademarked: https://www.linuxfoundation.org/legal/trademarks Thanks! |
I would still posit that any name that bears similarity with the official Kubernetes Gateway API subproject is going to lead to confusion. I feel this is less about trademark and more about respecting the work of the active Gateway API maintainers. |
|
Thanks @justaugustus - I just wanted to ensure people were aware of the legal line that happens quite a bit when projects get proposed both inside and outside of CNCF. The community line is a separate issue and I encourage both communities to talk to each other as this proposal makes it way through the open and transparency CNCF TOC project proposal process |
|
As a Kubernetes SIG Network chair and Gateway API maintainer, I also see some potential for confusion with the name. This name might insinuate a strong affiliation with both Kubernetes and Gateway API, however this project is not from Kubernetes SIG Network. Very happy to have a conversation and hear your thoughts about the naming. |
|
would be good for folks proposing this to head over to SIG Network / Gateway API meeting after kubecon. You can add an item to the agenda beforehand as well. https://github.com/kubernetes/community/blob/master/sig-network/README.md#meetings thanks! |
|
As another Gateway API maintainer, I agree the proposed name would be confusing, and also that any variation of "Kubernetes" as the only prefix here would be confusing. I'm assuming the goal is not to be a SIG-Network subproject, so I'd recommend finding a more unique name here. |
I want to second this as a sig-network chair. Giving the benefit of the doubt the name was given without any ill intent. Willing to sync up and discuss and come up with a plan. I believe kubeGateway was proposed. |
|
Looks like there was already a rebranding from gloo to k8sgateway just 2 days ago! and there is still a gloo repository under solo-io's github org forked from the above repo: |
As yet another Gateway API maintainer, +1 to this. If the project doesn't aim at being a SIG-Network subproject, I'd recommend finding a peculiar name, instead of any variations implicitly implying any kind of blessing or recommendation from SIG-Network. |
|
This really wasn’t the reaction we were hoping for :-( We put a lot of thought into choosing a descriptive name and initially settled on “kgateway,” only to discover that it was already taken. We even reached out to the owner of the repository but unfortunately didn’t have any luck. Looking at the CNCF landscape, we noticed projects like “k8sGPT”, “K8GB”, “k8up” which led us to believe that “k8sgateway” might also be acceptable. That said, no worries at all—we’re absolutely fine with changing the name to “kubegateway,” as @caniszczyk suggested. Thank you so much for the feedback! We’re excited to work closely with the relevant SIG Networking groups moving forward. |
|
@ilevine please let us know AFTER you have had a talk with them. |
|
Please don't interpret this (admittedly somewhat overwhelming) thread as any sort of judgement on the product or quality. As we discussed, we have to be very careful with the implications of "official" projects. We can document it until we are blue in the face, but people will still assume this is an officially sanctioned and supported project. If there are other projects naming themselves "k8s..." or "kube..." We should ask them to rename themselves, too. This one gets a double-whammy :) IMO "kube gateway" is not appreciably better, and I'll resist the urge to suggest names myself, since I know I am terrible at it . |
|
re: K8sGPT cc: @AlexsJones |
|
I also strongly believe that k8sgateway or kubegateway are not, in any way, appropriate names. To be clear, I make no comment about the product itself, and I have no objection to donating it to CNCF. I also completely understand not wanting to donate e.g. the Gloo name or the like to CNCF. However, I am very strongly opposed to any name that can give the impression that the project is a part of Kubernetes, or that it is in any way a reference or default Gateway API implementation. |
|
I updated the subject to say "kubegateway" according to @ilevine's comment here #1484 (comment) @kflynn from a CNCF Trademark perspective, we have no issue with anything kube* and is allowed by rules by independent open source projects in CNCF to use. k8s/kubernetes is trademarked and not allowed by default for new projects (unless the project lived in k8s). There are plenty of projects called kube* and is allowed by the current rules and has been going on for a long time. I'd encourage the community here to work together to resolve things as best as they can, but sometimes we do have overlapping projects in CNCF with separate communities that tackle similar problems... and that's OK! |
caniszczyk
changed the title
|
@caniszczyk I'm not speaking from a trademark perspective, but from the perspective of Gateway API. Since its inception, the Gateway API project has deliberately and intentionally avoided even the appearance of a single reference implementation: it is meant to be a cross-industry initiative, and it does not serve the project or the community for an implementation to claim that it is a reference implementation. This doesn't necessarily preclude the word "gateway" in the name, but it absolutely does imply that care in messaging is critical, as is care in communicating with the projects on which a new incubating project is built. |
|
Cross-posting from discussions. We seem to not not have trademark on "kube", but do on "k8s" and "kubernetes". Even so, this is all "within the family" -- asking projects to not call themselves "k8s-this" or "kube-that" seems perfectly tenable. We don't need legal enforcement. As for projects OUTSIDE of CNCF, if they call themselves "kube-something" I do think we should ask them politely, but with the full context of CNCF, to not do that. If you recall, "CRI-O" was originally "CRI-OCI" but OCI group asked to not do that, and we respected it. Within CNCF, the rules are our own, and we can (should, IMO) require non-k8s-owned projects avoid using "k8s"/"kube"/"kubernetes" in their names. |
|
From discussion: I don't think we can prevent a name like "kgateway". I don't love it, but at some point it becomes a request rather than a demand. My opinion is that a more memorable / unique name would be better for everyone, but I suspect we (k8s) have no real authority to forbid the use of the word "gateway" and/or the letter "k", even if "KSomething" implies some amount of offical-ness (not implying intent). I suspect that people will infer a stronger relationship than really exists, which will cause us (probably k8s people mostly) to have to clarify repeatedly that, despite the name, "kgateway" is not "the official kubernetes gateway". Personally, I think calling it something like "kragl" or "sooper" would be hilarious. Glue. Gloo. I think it's one of my very best ideas, which I guess says something about me. |
|
@thockin writes:
I dunno, Tim, I think "Kragl" is pretty inspired in this context. 👍 🙂 More seriously, I agree with everything you're saying about "kgateway". I think it's entirely reasonable for the CNCF to put its weight behind asking a project not to use that name (indeed, I would expect exactly that response if I were trying to donate a new service mesh named "kmesh"). Overly broad names breed confusion rather than understanding, and confusion doesn't help any of us. |
Yeah, I think the KDE folks have president on naming things KSomething. They predate k8s by a lot. :)
oh, I like kragl a lot :) |
|
fwiw, there may also be a few projects that use k8s or kube, as a suffix or in the middle of their names too: i.e https://cdk8s.io/ |
This will be a question for the TOC - they have the leeway to make renaming a condition of accepting a project, to avoid confusion (or for any other reason they might agree on). |
yep! |
|
The Kubernetes Steering Committee had a number of community members reach out to us following the highly visible keynote announcement of this project. This has triggered a broader conversation about projects in the expansive landscape occasionally using names that are confusing versus Kubernetes’s upstream projects, so we’ve discussed and made a formal, generic recommendation to the TOC here: https://lists.cncf.io/g/cncf-toc/message/8726 We have no comment as a committee on the specific adoption of this project, but we ask that going forward projects pick their own creative branding that does not conflict with our subprojects. Thank you, On a personal note: I did not intend for such a sprawling thread on this topic, just to raise the concerns of our contributors. I hope folks understand that I bear no ill will and that we only seek clarity. Thank you. |
K8sGateway Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Project Repo(s): https://github.com/k8sgateway/k8sgateway, https://github.com/k8sgateway/community
Project Site: https://k8sgateway.io
Sub-Projects: NA
Communication: https://cloud-native.slack.com/archives/C080D3PJMS4
Project points of contacts: Idit Levine, Lin Sun, Yuval Kohavi
Incubation Criteria Summary for K8sGateway
Application Level Assertion
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
Application Process Principles
Suggested
N/A
Required
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Required
Document agreement that project will adopt CNCF Code of Conduct.
CNCF Code of Conduct is cross-linked from other governance documents.
Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Required
Clearly defined and discoverable process to submit issues or changes.
Project must have, and document, at least one public communications channel for users and/or contributors.
List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
Documentation of how to contribute, with increasing detail as the project matures.
Demonstrate contributor activity and recruitment.
Engineering Principles
Suggested
Roadmap change process is documented.
History of regular, quality releases.
Required
Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This can also be satisfied by completing a General Technical Review.
Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
Document the project's release process.
Security
Note: this section may be augmented by a joint-assessment performed by TAG Security.
Suggested
N/A
Required
Clearly defined and discoverable process to report security issues.
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
Document assignment of security response roles and how reports are handled.
Document Security Self-Assessment.
Ecosystem
Suggested
N/A
Required
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)
The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.
Refer to the Adoption portion of this document.
Additional Information
The text was updated successfully, but these errors were encountered: