Drop links to third-party projects from multi-tenancy page #51014
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
language/en
liggitt
changed the title
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: 517d3e0b17fd9bc2023b6e8694614f7f43402442
|
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
I'm very disappointed by this: I can understand the reason for removing third-party tool links, but I don't get the point of removing Capsule, Kyverno, and Gatekeeper. Such projects have been donated to the CNCF, the same foundation which belongs Kubernetes to, and they enhance Kubernetes capabilities and specifically address specific Kubernetes features lack.
|
erikgb makes very fair point here.
|
Kubernetes is part of a larger ecosystem, like any open source project. A broad reading of this guideline would be inclusive of third party links. The loss of spaces to lift up third parties leads to those third parties having less attention, and ultimately less eyes and users. This leads to a smaller, less robust ecosystem, which inhibits the ultimate function of Kubernetes within the ecosystem. This PR could be seen as violating the guidelines linked above. |
Echoing my response from there: I understand the disappointment, but those are not equivalent. The Ingress API has no in-tree implementation, so it requires an external implementation to function at all. Users creating those objects without an Ingress controller installed would see the cluster as non-functional. Similarly for CNI, network policy, etc. There are not multi-tenant APIs Kubernetes provides without a backing implementation.
That reading would be so broad as to make the guidance not to include third-party links meaningless. The guideline gives very concrete examples, components Kubernetes depends on to function, not layers on top of Kubernetes. |
As someone who has studied the open source ecosystem as a whole: That's OK. The guidance should be changed. It's going to negatively impact your community. |
|
The change may be aligned with a literal / strict interpretation of the 3rd party documentation guideline, specifically However, when we authored the initial version of this doc from the wg-multitenancy the spirit of the work was to lean towards helping the community with real-world implementations and the context of Since without one of the mentioned 3rd party tools, the multi-tenancy features do not function, it seems best to continue to provide the 3rd party tool references to users who want to implement these features. This seems to be a fairly low maintenance and open process which allows any relevant OSS project to list themselves, and go through the review process. |
Please have a look at kubernetes/enhancements#5245 which is where I want the associated KEP to end up. Feedback is welcome, but bear in mind that this is accepted policy. We, Kubernetes, do not favor Linux Foundation solutions over other vendors. We do prefer open source (sorry Microsoft, who make the other node OS we support) but we will willingly integrate with closed-source things in the right circumstances. The motivations for KEP 1326 are absolutely still relevant. /lgtm I would be delighted to see a page similar to https://kubernetes.io/partners/ that embeds either the CNCF Landscape or something like it. Even better if we can embed relevant snippets in our docs in a way that is genuinely vendor-neutral and keeps docs maintainers away from needing to decide which things get included. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: enj, lmktfy The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
BTW, disappointed folks: you can blog about the things you want mentioned (no, we do not accept vendor pitches). I co-edit our blog and I'd be very happy to see incoming articles such as "How many clusters do you need?" (actual title of a talk I did last year) or "different ways to do Kubernetes multitenancy". The docs can even link to relevant blog articles, within reason. But we mostly don't list external vendors in our docs and until a lot more docs contributor capacity arrives, I don't see that changing. Did I mention we do not accept vendor pitches? Also, we do not accept vendor pitches. |
One of the headlines from a KubeCon and CloudNativeCon was: Building Together — as communities of the Open Source we should create bridge to let it thrive and generate added value knowledge via cross-pollination, this PR is creating a garden wall. The passive aggressive response to the remarks raised from some members of the community shows clearly this behavior. |
|
If a third-party tool helps solve problems that projects in the Kubernetes org don't solve, or they do it better for some specific use case, not mentioning that is doing a disservice to the community. A simple disclaimer placed somewhere close would be enough if the concern is that third-party links could be perceived as endorsements. Documentation should be judged based on its quality, and potential to help solve problems users have. If that occasionally means referencing third-party tools, why wouldn't you? This Not Invented Here policy isn't helping anyone. |
|
While I am generally opposed to this change, including the "Not Invented Here" policy, I see the point in Tim's comment:
Last part, about not putting doc maintainers in a bad position. Maintainers are doing a great job, but I wish community projects had better maintainer capacity. |
You're hitting a real problem, thanks for chiming here. There's a real fatigue for maintainers in crossing the chasm of awareness and maintenance: it's not the case of Kubernetes, widely adopted, known, and established. A project can thrive and catch more attention in several ways: not all developers are good at PR due to multiple reasons. Kubernetes has the luck of having a broader maintainers base on specific areas, such as the documentation tailoring specific topics, such as multi tenancy in this case. Speaking on behalf of Project Capsule project, we had several referrals from the Kubernetes documentation website, which helped us in these years to create more confidence from end users, and who knows, in getting aboard a new mainrainer which is doing a great job. This will not be possible anymore due to the said policy. We're fine (sic) as an established project, I'm just thinking for the emerging ones who couldn't benefit from the cross references in building a shared knowledge. Documentation will be a silos, offloading to blog posts which are:
In regard of the latter point, considering open source projects as vendors is absolutely a non sense, but the overall discussion by this person in the last messages is that Capsule, Kyverno, and OPA Gatekeeper are vendors, or part of a vendor such as the CNCF — it's the same as Kubernetes one, so what are we talking about? I understand the goal of SIG Docs, this issue received a feedback from a diverse set of people with different roles in the community we all belong to. Open Source is about collaboration, PoVs sharing, and strong opinions weakly held — no offense here, it seems to me this is not happening here. |
This is precisely the reason why allowing links to third party projects is a problem right? Linking to 3rd party projects on Kubernetes docs gives the impression that Kubernetes recommends these projects and that puts the burden on docs maintainers to validate that these projects actually should be and should continue to be promoted and recommended. It also puts the burden on them to keep the promotion fair across different alternative projects. Who's to say Capsule deserved that traffic from the Kubernetes docs? If you use lists, does that unfairly favor one over the other? I think it's fair to protect the docs maintainers from having to make this judgement. |
|
Hello, i'm Natali, one of the chairs of SIG Docs, and i'd like to try and chime in here on a few points, since there has been no actual leadership from our SIG involved in this discussion or in the approval of this PR (however, at least one approver has given their own agreement, which is fine). Firstly, i need to address the following:
"it's not the case for Kubernetes" is unfortunately not true. Yes, we're a big project, and widely adopted, and yes, in some areas, it looks like there is a wealth of maintainers in I can absolutely understand that its difficult to think of the word "vendor" and also imagine other open source projects, and if folks can think of another word that would better describe this (or perhaps we have to write third-party vendors and projects instead of content?), then we're open to that feedback and welcome it. However, our third-party content policy has existed for quite a while, and it seems like that its this specific application of it to the multi-tenancy docs that is causing concern. I also see @JimBugwadia's comment about the initial WG's intentions, and i think bringing that up with the folks involved in multi-tenancy work is the right path here, as opposed to a docs PR (and I would absolutely encourage you, Jim, and others, to bring this conversation to the right place so that people with actual context and leadership roles in the project can comment – more below). This policy was put in place to ensure that we don't show preference to specific companies or technologies, and the decision has been made across the project to adhere to this policy. However, policies and project leadership do evolve, as has the case with this. It can feel easy to blame SIG Docs, and nothing is stopping you from doing so, but please know that this is a project-wide policy, and the Kubernetes Steering Committee approved it to be so. I would welcome discussion about whether CNCF-ecosystem projects consistute an exception from this policy, and if folks wish to have this discussion, then lets do so! I would suggest an issue, in kubernetes/steering, so that we can address concerns from the community. Back-and-forth comments on a PR, or upset posts on LinkedIn, aren't going to cultivate worthwhile discussion, but these have at least brought some attention to a policy that has existed for a very long time, but whose application seems to now be a concern because of the projects it affects with the change in this PR. I want to call out that i think the communication of the change to the multi-tenancy docs could have been better, and we as project leads do need to get better at communication overall. We even talked about content on the initial "chopping block" when the KEP for this policy was introduced. Was there any communication between projects about how much they relied on this inclusion in the docs? Or is this a general issue with the policy? Again, i am not sure we're getting to the bottomm of any issue in this PR outside of airing grievances, so lets do this is the correct place. There's been call-out that it looks like Kubernetes isn't being collaborative because of this policy – yet, in my 3+ years as a lead of SIG Docs, this is the first time i am seeing this complaint based on an old policy that is only now being applied to certain areas of the docs because we've lacked the time and active maintainers to do so, or, quite simply (and probably more understandable to many folks in this thread), other issues and fixes took priority. I once again invite the folks on this thread, many of who have contributed to this project and its docs (and we thank you a lot for this!), to have this discussion in a place where action can come from it. Thanks for bringing awareness to these concerns. |
|
As @natalisucks mentioned I've opened kubernetes/steering#292, in order for the discussion to go on. |
Description
Drops third-party links and warnings from https://kubernetes.io/docs/concepts/security/multi-tenancy/ to match guidance at https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content
Also drops link to archived kubernetes-sigs project.