add qbo to list of distributions

[alexeadem]

This PR adds qbo, to the list of distributions: Kubeflow v1.7.0 and v1.8.0 + Nvidia GPU Operator Documentation

https://docs.qbo.io/#/ai_and_ml?id=kubeflow

Kubeflow + Nvidia GPU Operator + Docker-in-Docker + Cgroups v2

https://www.qbo.io/#/blog_part_2_kubeflow

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[google-oss-prow[bot]]

Hi @alexeadem. Thanks for your PR.

I'm waiting for a kubeflow 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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[alexeadem]

Added the missing CLA

[andreyvelich]

You need to sign all of your commits to pass DCO

[andreyvelich]

I think, you should add yourself to the Kubeflow Org to be listed in the Owners files: https://github.com/kubeflow/internal-acls?tab=readme-ov-file#joining-kubeflow-github-organization Otherwise, you can remove Owners files for now.

[thesuperzapper]

@andreyvelich if he meets the pull request and sponsorship requirements, let's add him.

Otherwise, we really can't just be adding people, as it does give them permissions.

[alexeadem]

I think, you should add yourself to the Kubeflow Org to be listed in the Owners files: https://github.com/kubeflow/internal-acls?tab=readme-ov-file#joining-kubeflow-github-organization Otherwise, you can remove Owners files for now.

Ok I removed OWNERS file for now.

[andreyvelich]

@alexeadem Please can you sign your commits for DCO ?

[james-jwu]

/lgtm But waiting for DCO to be signed.

[jbottum]

Is QBO the name of the company ? I cannot find it in an internet search.

[alexeadem]

Is QBO the name of the company ? I cannot find it in an internet search.

@jbottum https://bizfileonline.sos.ca.gov/search/business

QBO LLC (202031010524)

[alexeadem]

@alexeadem Please can you sign your commits for DCO ?

@andreyvelich. Done

[thesuperzapper]

@alexeadem while we're halfway through transferring to the DCO, the repo is still configured to require the Google CLA to be signed.

Are you able to sign it?

[alexeadem]

@alexeadem while we're halfway through transferring to the DCO, the repo is still configured to require the Google CLA to be signed.

Are you able to sign it?

@thesuperzapper Done. CLA shows ok now.

[thesuperzapper]

@jbottum I am not sure its correct to call this a "packaged distribution", from my look at https://docs.qbo.io/#/qke?id=kubeflow (which is the "website link"), it just looks like a guide to install the kubeflow/manifests:

[alexeadem]

I think we should create a table under the "Raw Kubeflow Manifests" section for guides like this one (which install raw kubeflow/manifests), rather than including them under "Packaged Distributions".

That will make it more clear to users what they are actually getting.

PS: the "Nutanix" distribution is also just a brief install guide for kubeflow/manifests, so we should probably move it under this "Raw Kubeflow Manifests" table also.

That will apply also for IBM and probably other Kubernetes distributions. IKS, AKS, GKE (and QKE) are first and foremost Kubernetes distros that support Kubeflow installation by providing guidance on how to deploy them in their distros (or specific packages if they are unable to deploy directly from upstream). Specifically for qbo the goal is to support upstream installation methods with little to no modification and provide metal performance in Kubernetes.

I believe the differentiation should be between packaged solutions whose main purpose is deploying kubeflow independent of the platforms (k8s or other), and Kubernetes distributions that support kubeflow upstream or other. For Kubernete distros I would make also CNCF conformance part of the requirement

[thesuperzapper]

That will apply also for IBM and probably other Kubernetes distributions. IKS, AKS, GKE (and QKE) are first and foremost Kubernetes distros that support Kubeflow installation by providing guidance on how to deploy them in their distros (or specific packages if they are unable to deploy directly from upstream). Specifically for qbo the goal is to support upstream installation methods with little to no modification and provide metal performance in Kubernetes.

I believe the differentiation should be between packaged solutions whose main purpose is deploying kubeflow independent of the platforms (k8s or other), and Kubernetes distributions that support kubeflow upstream or other. For Kubernete distros I would make also CNCF conformance part of the requirement

@alexeadem While I agree that distinguishing generic vs specific "packaged distributions" would be a good idea and would help the user, it does not change the fact that the QBO guide doesn't really fit the definition of a "packaged distribution".

For reference, all other distributions maintain a fork of kubeflow/manifests (however minimal it might be).

Either way, I have raised a PR to help you get a presence on the website by creating a new PR to create the "platform-specific guides" section and adding QBO:

• https://github.com/kubeflow/website/pull/3700

[thesuperzapper]

/hold

Pending discussion of alternative PR https://github.com/kubeflow/website/pull/3700

[alexeadem]

That will apply also for IBM and probably other Kubernetes distributions. IKS, AKS, GKE (and QKE) are first and foremost Kubernetes distros that support Kubeflow installation by providing guidance on how to deploy them in their distros (or specific packages if they are unable to deploy directly from upstream). Specifically for qbo the goal is to support upstream installation methods with little to no modification and provide metal performance in Kubernetes. I believe the differentiation should be between packaged solutions whose main purpose is deploying kubeflow independent of the platforms (k8s or other), and Kubernetes distributions that support kubeflow upstream or other. For Kubernete distros I would make also CNCF conformance part of the requirement

@alexeadem While I agree that distinguishing generic vs specific "packaged distributions" would be a good idea and would help the user, it does not change the fact that the QBO guide doesn't really fit the definition of a "packaged distribution".

For reference, all other distributions maintain a fork of kubeflow/manifests (however minimal it might be).

Either way, I have raised a PR to help you get a presence on the website by creating a new PR to create the "platform-specific guides" section and adding QBO:

• add QBO and "raw manifests" guides table #3700

@thesuperzapper Got it. I like the idea of the raw manifests. Looking forward to seeing qbo there. Alternately I can maintain a minimal kubeflow/manifests as well in the future. Thanks for the help.

[google-oss-prow[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexeadem, andreyvelich, hbelmiro, terrytangyuan

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: - ~~[OWNERS](https://github.com/kubeflow/website/blob/master/OWNERS)~~ [andreyvelich,terrytangyuan] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[thesuperzapper]

I still think we should shorten the "target platform" in this PR, as it's at least twice as long as every other one in the table (and makes the table harder to read).

We can just use QBO Kubernetes Engine as proposed in: https://github.com/kubeflow/website/pull/3672#discussion_r1531441663

[alexeadem]

I still think we should shorten the "target platform" in this PR, as it's at least twice as long as every other one in the table (and makes the table harder to read).

We can just use QBO Kubernetes Engine as proposed in: #3672 (comment)

@thesuperzapper do you want me to update the PR with that change?

[thesuperzapper]

@alexeadem I will unhold if you do, so it will get merged.

[andreyvelich]

I still think we should shorten the "target platform" in this PR, as it's at least twice as long as every other one in the table (and makes the table harder to read). We can just use QBO Kubernetes Engine as proposed in: #3672 (comment)

@thesuperzapper do you want me to update the PR with that change?

@alexeadem I think, QBO Kubernetes Engine (QKE) should work similar to others: GKE, EKS, IKS, etc. Please update it and we can merge it.

[alexeadem]

@thesuperzapper and @andreyvelich. Shortened to QBO Kubernetes Engine (QKE) as suggested. Thanks

[thesuperzapper]

/unhold