Change Kubeflow Distributions Table

[andreyvelich]

Related: https://github.com/kubeflow/website/pull/3641, https://github.com/kubeflow/website/pull/3643.

We discussed in our latest KSC meeting on how we should improve our Kubeflow distributions table. Recording: link Passcode: EH+vu2h7 Summary:

• We think, that when Kubeflow users select distribution, they just want to know: distribution target platform, maintainers, and Kubeflow supported version. It doesn't matter how distribution is named.

• Thus, to address comments that @thesuperzapper raised before about kubeflow on AWS we removed distribution name from the table. For distributions where name is important we moved it to the second column (e.g. Charmed Kubeflow and deployKF only).

• We sort this table as follows: Target Platform Name + Kubeflow Version. All certified Kubernetes support goes first.

  • Update (2024-03-12). After recent KSC call we decided to always sort table by maintainer name.

• We think, that we should remove legacy distributions from our page. Some users still want to get support from public cloud providers like AWS or GCP even if they don't support latest Kubeflow version. For example, users might feel comfortable with Kubeflow 1.3 - 1.7 versions without official support for the latest Kubeflow release.

  • If distributions no longer exists, we will remove it from the Kubeflow website.

@thesuperzapper I added your useful changes from this PR: https://github.com/kubeflow/website/pull/3643 @juliusvonkohout Let me know if you think we should modify text as you suggested here: https://github.com/kubeflow/website/pull/3643#discussion_r1508775364.

cc all working groups and distribution owners.

cc @kubeflow/kubeflow-steering-committee @kubeflow/wg-notebooks-leads @kubeflow/wg-training-leads @tenzen-y @kuizhiqing @kubeflow/wg-manifests-leads @kubeflow/release-team @kubeflow/wg-pipeline-leads @alexeadem @liuqi @xujinheng @julioo @rimolive @davidspek @nagar-ajay @Tomcli @yhwang @gkcalat @zijianjoy @Linchin @ca-scribner @surajkota @zijianjoy

/hold for review

[google-oss-prow[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andreyvelich

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] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[rimolive]

I'm curious about the kubeflow versions column. Does it make sense to use 1.8.x (for example) instead? I don't know what is the workflow for patches releases, but I saw no reference that distributions need to test patch releases to say it supports the latest patch release.

[ca-scribner]

These changes make sense to me.

I'm +1 for being aggressive in culling the list to remove older versions/distros not supported anymore, but I know there's been some debate in the community meetings about how we should have a criteria for that before doing it. To me removing anything where:

• the company is no longer actively supporting it (eg: Arrikto), or
• latest supported version is older than current release - 1 (so anything <1.7.x atm)

[juliusvonkohout]

"@juliusvonkohout Let me know if you think we should modify text as you suggested here: #3643 (comment)."

@andreyvelich yes please.

[andreyvelich]

I'm curious about the kubeflow versions column. Does it make sense to use 1.8.x (for example) instead? I don't know what is the workflow for patches releases, but I saw no reference that distributions need to test patch releases to say it supports the latest patch release.

It's a good point @rimolive, but right now distribution owners control their version in these files: https://github.com/kubeflow/website/blob/master/layouts/shortcodes/gke/latest-version.html, maybe we could ask them to modify the patch version in the following PRs.

[andreyvelich]

These changes make sense to me.

I'm +1 for being aggressive in culling the list to remove older versions/distros not supported anymore, but I know there's been some debate in the community meetings about how we should have a criteria for that before doing it. To me removing anything where:

• the company is no longer actively supporting it (eg: Arrikto), or
• latest supported version is older than current release - 1 (so anything <1.7.x atm)

I agree with the first point @ca-scribner, but I don't think we should be too aggressive with the latest release support. As I said some users might still use Kubeflow 1.3 or Kubeflow 1.4, so maybe we can think about this: Release - 7, like in EKS: https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html What do you think @kubeflow/kubeflow-steering-committee @ca-scribner ?

[andreyvelich]

@juliusvonkohout I added the following statement: Nevertheless we welcome contributions and bug reports very much. But I have a few concerns about these 2 sentences:

• will not provide unpaid support: Won't users be confused that we can provide some paid support ?
• please consider using a packaged distribution or paid consulting: We didn't introduce paid consulting yet, do we want to add this info in the Kubeflow website ?

@ca-scribner @rimolive @kubeflow/kubeflow-steering-committee @thesuperzapper Your thoughts ?

[juliusvonkohout]

@juliusvonkohout I added the following statement: Nevertheless we welcome contributions and bug reports very much. But I have a few concerns about these 2 sentences:

* `will not provide unpaid support `: Won't users be confused that we can provide some paid support ?

* `please consider using a packaged distribution or paid consulting`: We didn't introduce paid consulting yet, do we want to add this info in the Kubeflow website ?

@ca-scribner @rimolive @kubeflow/kubeflow-steering-committee @thesuperzapper Your thoughts ?

Most commercial distributions and freelancers provide paid support. Usually maintainers such as @thesuperzapper myself and @terrytangyuan or distributions such as charmed Kubeflow and deploykf if I remember correctly.

It is an interesting question, how we can state this on the website. I think we should definitely do so since this finances the open source development in the end and helps the project significantly.

In the end it could be something like "Many commercial distributions and freelancers around Kubeflow provide paid support if needed.

There is also limited best-effort support on the GitHub issue tracker, but it is primarily meant for development.

Nevertheless we welcome documentation, code contributions contributions and bug reports very much."

[andreyvelich]

There is also limited best-effort support on the GitHub issue tracker, but it is primarily meant for development.

Not sure if we can be confident with such statement since various distributions might work with their users differently.

Many commercial distributions and freelancers around Kubeflow provide paid support if needed

I like this sentence more, but the question is what is the user value for this statement being in kubeflow.org ?

[juliusvonkohout]

There is also limited best-effort support on the GitHub issue tracker, but it is primarily meant for development.

Not sure if we can be confident with such statement since various distributions might work with their users differently.

Many commercial distributions and freelancers around Kubeflow provide paid support if needed

I like this sentence more, but the question is what is the user value for this statement being in kubeflow.org ?

It shows that we have corporate backing with reliable support contracts available via independent third parties. As an interested potential user feel free to try out Kubeflow as PoC in your company or university and if you want to go to production we can provide the necessary enterprise configuration.

[rimolive]

There is also limited best-effort support on the GitHub issue tracker, but it is primarily meant for development.

Not sure if we can be confident with such statement since various distributions might work with their users differently.

Many commercial distributions and freelancers around Kubeflow provide paid support if needed

I like this sentence more, but the question is what is the user value for this statement being in kubeflow.org ?

It shows that we have corporate backing with reliable support contracts available via independent third parties. As an interested potential user feel free to try out Kubeflow as PoC in your company or university and if you want to go to production we can provide the necessary enterprise configuration.

I think better than getting into support details, we should come up with a list of the companies backing Kubeflow and saying that it's part of CNCF. Other than that it's just explaining how Open Source works, and this is out of KF docs scope.

[andreyvelich]

I have similar thoughts as @rimolive, expending our adopters list with updated information about users, enterprises, distributions, projects, etc. should be sufficient to show Kubeflow adoption. As an example, see how Istio shows this: https://istio.io/latest/about/ecosystem/

[thesuperzapper]

I have similar thoughts as @rimolive, expending our adopters list with updated information about users, enterprises, distributions, projects, etc. should be sufficient to show Kubeflow adoption. As an example, see how Istio shows this: https://istio.io/latest/about/ecosystem/

@andreyvelich we actually already have a "Get Support" page the under "Getting Gtarted" section, we could link people to it from the "Installing Kubeflow" page, under a "Who can help me deploy Kubeflow?" or similar heading.

But before we do that, we should clean up the "Get Support" page, as its really out of date, and has a random list of "Support from providers in the Kubeflow ecosystem" including Arrikto (which no longer exists as a company).

I have been hesitant to update that page because its just another minefield where we have to answer "who gets to be on the list", lol.

[andreyvelich]

I have similar thoughts as @rimolive, expending our adopters list with updated information about users, enterprises, distributions, projects, etc. should be sufficient to show Kubeflow adoption. As an example, see how Istio shows this: https://istio.io/latest/about/ecosystem/

@andreyvelich we actually already have a "Get Support" page the under "Getting Gtarted" section, we could link people to it from the "Installing Kubeflow" page, under a "Who can help me deploy Kubeflow?" or similar heading.

But before we do that, we should clean up the "Get Support" page, as its really out of date, and has a random list of "Support from providers in the Kubeflow ecosystem" including Arrikto (which no longer exists as a company).

I have been hesitant to update that page because its just another minefield where we have to answer "who gets to be on the list", lol.

That's great point @thesuperzapper! I think, we should keep this "Get Support" table updated. @juliusvonkohout @thesuperzapper Should we have a link from the Installing Kubeflow page to this table ?

[andreyvelich]

@julioo @lcliuqi @xujinheng @mosabami Please can you comment on this PR if you are still willing to be listed as Kubeflow distribution owners ?

[liuqi]

@julioo @lcliuqi @xujinheng @mosabami Please can you comment on this PR if you are still willing to be listed as Kubeflow distribution owners ?

Yes. @xujinheng and I are maintainers of Kubeflow on vSphere. We still want Kubeflow on vSphere listed. And we are working on the 1.8 verification and distribution.

btw, my id is @liuqi Thank you!

[xujinheng]

@julioo @lcliuqi @xujinheng @mosabami Please can you comment on this PR if you are still willing to be listed as Kubeflow distribution owners ?

Yes, I am willing to be listed as a Kubeflow distribution owner. Thanks

[andreyvelich]

We need to add you to the Kubeflow org, so we can list you in the OWNERs files @liuqi @xujinheng You might need to submit PR in https://github.com/kubeflow/internal-acls to add yourself.

[liuqi]

We need to add you to the Kubeflow org, so we can list you in the OWNERs files @liuqi @xujinheng You might need to submit PR in https://github.com/kubeflow/internal-acls to add yourself.

Sure. Will do that. Thank you!

[andreyvelich]

In our recent KSC meeting we decided to modify title order for distribution table: Maintainer, Kubeflow Version, Target Platform, Website.

Ordering will be always by maintainer name. Similar to what CNCF is doing for Certified Kubernetes distributions: https://www.cncf.io/training/certification/software-conformance/ cc @kubeflow/kubeflow-steering-committee

[thesuperzapper]

@andreyvelich based on the call today, I think the consensus was that merging this with two small changes would be acceptable (and in line with the KSC's decision):

1. Making the separation between Maintainer and Distribution Name more clear:
   • Changing the title to Maintainer // Distribution Name
   • Making the separator between the names // rather than /
2. Removing any of the invalid OWNERS (we can add them again once they become members)

[andreyvelich]

@liuqi @xujinheng Please can you accept Kubeflow GitHub org invitation ? You should get it in your GitHub email.

[andreyvelich]

I will remove @mosabami @julioo from OWNERs files to unblock this PR since they are not part of Kubeflow GitHub org. Let's create followup PRs to add them to the Kubeflow GitHub org.

[andreyvelich]

As we discussed on today's Kubeflow community call, we want to merge this PR to unblock @alexeadem with QBO distribution: https://github.com/kubeflow/website/pull/3672 before the KubeCon 2024 Paris next week. We can discuss improvements in the followup PRs.

Please review this PR and give your /lgtm if you don't have any strong objections to move this forward.

/assign @kubeflow/kubeflow-steering-committee @kubeflow/wg-notebooks-leads @kubeflow/wg-training-leads @tenzen-y @kuizhiqing @kubeflow/wg-manifests-leads @kubeflow/release-team @kubeflow/wg-pipeline-leads @alexeadem @liuqi @xujinheng @julioo @rimolive @davidspek @nagar-ajay @Tomcli @yhwang @gkcalat @zijianjoy @Linchin @ca-scribner @surajkota @zijianjoy @mosabami @julioo @juliusvonkohout

[rimolive]

/lgtm

[xujinheng]

/verify-owners /lgtm

[kuizhiqing]

/lgtm

[liuqi]

/lgtm

[andreyvelich]

Based on our recent discussion with @thesuperzapper and @kubeflow/kubeflow-steering-committee, we made this final small change on how we show distribution name in the first column. If PR looks good to you, let's merge it.

[andreyvelich]

/hold cancel

[thesuperzapper]

Thanks for all your work @andreyvelich

/lgtm