community: ensure manifests description is vendor-neutral #4071
Conversation
Signed-off-by: Mathew Wicks <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| @@ -339,9 +339,8 @@ The following table lists distributions which are <em>maintained</em> by their r | |||
|
|
|||
| ### Kubeflow Manifests | |||
|
|
|||
| The Kubeflow manifests are a collection of community maintained manifests to install Kubeflow in popular Kubernetes clusters such as Kind (locally), Minikube (locally), Rancher, EKS, AKS, GKE. | |||
There was a problem hiding this comment.
I would prefer not to change this line as it gives an idea to new users that they can get use the manifest to deploy kubeflow on any of the popular Kubernetes platforms available. The change below highlights only kind clusters which may miscommunicate the information that the manifests work only on kind. @juliusvonkohout any comments
There was a problem hiding this comment.
Up until very recently (30 days ago) no reference to and specific Kubernetes distribution was included, and this did not confuse anyone.
However, the current wording is misleading, as the manifests are only tested to deploy a minimum-viable Kubeflow Platform on Kind, with no guarantees for other platforms.
It's also important to note that the Manifests WG charter explicitly prohibits the inclusion of (kubernetes) distribution-specific manifests, so even mentioning specific distributions verges on violating the charter.
There was a problem hiding this comment.
Up until very recently (30 days ago) no reference to and specific Kubernetes distribution was included, and this did not confuse anyone.
However, the current wording is misleading, as the manifests are only tested to deploy a minimum-viable Kubeflow Platform on Kind, with no guarantees for other platforms.
It's also important to note that the Manifests WG charter explicitly prohibits the inclusion of (kubernetes) distribution-specific manifests, so even mentioning specific distributions verges on violating the charter.
@thesuperzapper my comment is more about the wording that you are using i.e. The Kubeflow Manifests are community maintained kustomize manifests which are tested to deploy a minimum-viable Kubeflow Platform on **[Kind](https://kind.sigs.k8s.io/)** clusters. while the old one (30 days ago) only had the Kubeflow manifests are a collection of community maintained manifests. The change you are proposing kind of throws users that the manifests will only work on kind which is what I am asking you to correct. The previous one explicitly dind't mention only kind and hence it never sounded confusing to new users like me. But the one you are proposing is what i find a bit confusing/misleading and hence the ask to update it to match the older one to avoid any confusions.
There was a problem hiding this comment.
We could revert the change from 30 days ago, and not reference any specific distribution. However, it's important for people to understand that we only officially test the kubeflow/manifests on Kind, and make no guarantees about any other Kubernetes environment.
There is also a governance requirement (from the Manifests WG charter) to ensure that no specific distribution gets preference in the kubeflow/manifests, hence why we only test Kind. This is critical for the health of the project, and ensuring we remain vendor neutral.
PS: I want to stress that as always, anyone is welcome to make distributions for specific platforms (and many have), but those are not official, nor can they live in kubeflow/manifests.
There was a problem hiding this comment.
I agree its better to highlight that they have been tested to work only on kind and not on other kubernetes platforms
There was a problem hiding this comment.
We are vendor neutral, we just work fine on the most Kubernetes clusters.
So I explicitly want to keep the existing message. We have many users who succesfully install from Kubeflow manifest on these types of Kubernetes clusters.
|
@thesuperzapper I just put a comment on the proposed change. The existing wording looks better to me. |
|
We discussed changes for a long time in the KSC and we will continue to get exactly those questions and users raising issues. This paragraph covers many questions that we typically get, so it is very useful. Even if we change it to Also the updated diagram in https://github.com/kubeflow/website/pull/4038/files shows that we as Kubeflow try to run on that infrastructure. |
Related: #4028
Related: #4014
/area community
What this PR does
This PR proposes an update to the manifests introduction paragraph that clarifies what the manifests actually are.
See diff for the current proposal.
Motivation
@kubeflow/kubeflow-steering-committee I am deeply concerned about a recent change to the manifests description that was merged without wider discussion with the community.
In PR #4028 (about 30 days ago), the manifests description was updated to the following:
This wording is misleading, as the manifests are currently only tested to deploy a minimum-viable Kubeflow Platform on Kind, with no guarantees for other platforms.
It's also important to note that the Manifests WG charter explicitly prohibits the inclusion of (kubernetes) distribution-specific manifests, so even mentioning specific distributions verges on violating the charter.