Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Kubeflow Distributions Table #3693

Merged
merged 15 commits into from
Mar 13, 2024

Conversation

andreyvelich
Copy link
Member

@andreyvelich andreyvelich commented Mar 1, 2024

Related: #3641, #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: #3643
@juliusvonkohout Let me know if you think we should modify text as you suggested here: #3643 (comment).

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

Signed-off-by: Andrey Velichkevich <[email protected]>
Signed-off-by: Andrey Velichkevich <[email protected]>
Copy link

[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:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Signed-off-by: Andrey Velichkevich <[email protected]>
Signed-off-by: Andrey Velichkevich <[email protected]>
@@ -0,0 +1,2 @@
approvers:
- ca-scribner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one might be a copy-paste error - I don't think it is me :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, it should be thesuperzapper, lol:

Suggested change
- ca-scribner
- thesuperzapper

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch, let me fix it.

@rimolive
Copy link
Member

rimolive commented Mar 1, 2024

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
Copy link

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)

Copy link
Member

@thesuperzapper thesuperzapper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andreyvelich I really like the idea of distinguishing "generic" from "specific" distributions.

See my comment #3693 (comment) for my specific suggestions.

</table>
</div>

### Legacy Distributions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have accidentally left all the legacy distributions (and placed them under the maintained table), if they aren't in a separate table, let's remove them.

We need to remove:

  • Argoflow
  • Kubeflow on OpenShift
  • Arrikto Enterprise Kubeflow

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will remove Argoflow + Arrikto, but for OpenShift can we can confirmation from the RedHat team @rimolive @terrytangyuan @rareddy @kubeflow/red-hat ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Red Hat is preparing to help with kubeflow 1.9 distribution testing. Let's keep it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, thanks for confirming @rimolive!

Kubeflow is an end-to-end Machine Learning (ML) platform for Kubernetes, it provides components for each stage in the ML lifecycle, from exploration through to training and deployment.
Operators can choose what is best for their users, there is no requirement to deploy every component.
To read more about the components and architecture of Kubeflow, please see the <a href="/docs/started/architecture/">Kubeflow Architecture</a> page.
Learn more about Kubeflow in the [Introduction](/docs/started/introduction/) and
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can put a newline here for visual separation:

Suggested change
Learn more about Kubeflow in the [Introduction](/docs/started/introduction/) and
Learn more about Kubeflow in the [Introduction](/docs/started/introduction/) and

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems not to be addressed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in reply to a suggestion for a newline.

It was added a few commits ago, I can see it on the test website:

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM


<div class="table-responsive">
<div class="table-responsive distributions-table-active">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You forgot to port the style changes which added this CSS class:

See the ./assets/scss/_styles_project.scss file diff form: https://github.com/kubeflow/website/pull/3643/files

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

Comment on lines 38 to 40
Some distributions can be deployed on all certified Kubernetes
distributions <sup>[<a href="https://kubernetes.io/partners/#conformance">1</a>]</sup>, some of them
can be deployed only in specific Kubernetes environment (e.g. EKS or GKE).
Copy link
Member

@thesuperzapper thesuperzapper Mar 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are going to make the distinction between distributions for all Kubernetes, and ones for only a specific platform, I think it makes sense to split the tables up into "generic" and "specific" with different columns:


"Generic" Table:

Some Kubeflow distributions can be deployed on [all certified Kubernetes
distributions](https://kubernetes.io/partners/#conformance):
Distribution Name Kubeflow Version Maintainer Links
Charmed Kubeflow 1.8.0[Release Notes] Canonical Website
deployKF 1.7.0[Version Matrix] Aranui Solutions Website

"Specific" Table:

Other Kubeflow distributions target a specific Kubernetes platform:
Platform Kubeflow Version Maintainer Links
Google Kubernetes Engine (GKE) 1.8.0[Release Notes] Google Cloud Website
IBM Cloud Kubernetes Service (IKS) 1.8.0[Release Notes] IBM Cloud Website
... ... ... ...

Copy link
Member Author

@andreyvelich andreyvelich Mar 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we discussed this before, so your suggestion @thesuperzapper is to name Distributions as:

  • Generic Distributions
  • Specific Distributions

What do others think about it @ca-scribner @kubeflow/kubeflow-steering-committee @juliusvonkohout ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably yes. Which table should go first? Maybe the specific ones?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will raise this question on tomorrow's call.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andreyvelich I think putting the "generic" table first is more in the spirit of Kubeflow as a "generic" platform.

I worry that listing the "specific" distributions first will imply that the first platform on that table is the "recommended platform for Kubeflow". (We are already trying to shake the perception that Kubeflow is a Google-focused product).

Also, users will already gravitate toward the distribution targeting their specific platform, so it just doubly disadvantages the generic distributions by putting them second.

However, I understand that I may be a little biased (I maintain deployKF), so I am happy to see what others think.

Copy link
Member

@thesuperzapper thesuperzapper Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on today's community meeting, I think the consensus was to keep a single table, and to re-add the "Distribution Name" column (but keep it empty for distributions initially, until they make a PR to update the website with a non "Kubeflow on XXXX" name).

See my comment here for more details: #3693 (comment)

@@ -5,243 +5,255 @@ weight = 20

+++

## What is Kubeflow?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks better as H3, like the How to install Kubeflow? below it:

Suggested change
## What is Kubeflow?
### What is Kubeflow?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to keep titles with the same font if it is not sub-title. Like in Architecture page: https://deploy-preview-3693--competent-brattain-de2d6d.netlify.app/docs/started/architecture/#conceptual-overview.
So all title fonts on the same level will be consistent.

So if you don't want to make How to install Kubeflow? subtitle, I can change it as follows:

## How to install Kubeflow? 

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andreyvelich either make both of them H2 or both of them H3, it's weird to have them different.

I prefer using H3 (smaller title) for the intro questions and H2 (bigger title) for the later sections. The focus of this page is "Installing Kubeflow", so we want to draw the reader's attention to the later headings (which already use H2).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will make them both H2. If we make the first title H3, website will show outline not accurate
Screenshot 2024-03-08 at 13 07 00

<td>
All Certified Kubernetes Distributions <sup>[<a href="https://kubernetes.io/partners/#conformance">1</a>]</sup>
Amazon Elastic Kubernetes Service (EKS)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think we should consider removing this distribution, AWS has indicated they are no longer supporting it, so it's a bit crazy to include it (which will make people adopt a distribution that will not get any updates):

Here is their announcement that they will not support 1.8:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ananth102 you're the only person to commit on the awslabs/kubeflow-manifests repo in the last 5 months, what is the status of that repo?

Copy link
Member Author

@andreyvelich andreyvelich Mar 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have different thoughts here.
Since EKS is one of the most popular Kubernetes environment and many folks are considering to use Kubeflow distribution that was created and was maintained by AWS folks, we might want to keep it for a while.
Even that AWS was not participating in the recent Kubeflow release.
In the future, AWS might work on this again.
Users are aware that this distribution doesn't support the latest Kubeflow release, and they can take this risk.

Also, as I said here: #3693 (comment), we should list distributions with release-7 support.

cc @kubeflow/kubeflow-steering-committee @surajkota @jsitu777 @ryansteakley

</td>
<td>
<a href="https://awslabs.github.io/kubeflow-manifests">Website</a>
{{% canonical/latest-version %}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add the link to Charmed Kubeflow's release notes, like the other distributions:

Suggested change
{{% canonical/latest-version %}}
{{% canonical/latest-version %}} <sup>[<a href="https://charmed-kubeflow.io/docs/release-notes">Release Notes</a>]</sup>

@juliusvonkohout
Copy link
Member

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

@andreyvelich yes please.

@andreyvelich
Copy link
Member Author

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
Copy link
Member Author

andreyvelich commented Mar 4, 2024

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 ?

Signed-off-by: Andrey Velichkevich <[email protected]>
Signed-off-by: Andrey Velichkevich <[email protected]>
Signed-off-by: Andrey Velichkevich <[email protected]>
Signed-off-by: Andrey Velichkevich <[email protected]>
@andreyvelich
Copy link
Member Author

@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
Copy link
Member

@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
Copy link
Member Author

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 ?

@andreyvelich
Copy link
Member Author

andreyvelich commented Mar 12, 2024

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

Signed-off-by: Andrey Velichkevich <[email protected]>
@thesuperzapper
Copy link
Member

@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
Copy link
Member Author

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

@andreyvelich
Copy link
Member Author

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.

Signed-off-by: Andrey Velichkevich <[email protected]>
@andreyvelich
Copy link
Member Author

andreyvelich commented Mar 12, 2024

As we discussed on today's Kubeflow community call, we want to merge this PR to unblock @alexeadem with QBO distribution: #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

Copy link
Member

@tenzen-y tenzen-y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise lgtm.

Kubeflow is an end-to-end Machine Learning (ML) platform for Kubernetes, it provides components for each stage in the ML lifecycle, from exploration through to training and deployment.
Operators can choose what is best for their users, there is no requirement to deploy every component.
To read more about the components and architecture of Kubeflow, please see the <a href="/docs/started/architecture/">Kubeflow Architecture</a> page.
Learn more about Kubeflow in the [Introduction](/docs/started/introduction/) and
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems not to be addressed.

1. [Use a packaged distribution](#packaged-distributions-of-kubeflow)
2. [Use the raw manifests](#raw-kubeflow-manifests) <sup>(for advanced users)</sup>
1. [**Packaged Distributions**](#packaged-distributions-of-kubeflow)
1. [**Raw Manifests**](#raw-kubeflow-manifests) <sup>(advanced users)</sup>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
1. [**Raw Manifests**](#raw-kubeflow-manifests) <sup>(advanced users)</sup>
2. [**Raw Manifests**](#raw-kubeflow-manifests) <sup>(advanced users)</sup>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Markdown allows to use the same number twice, and it makes it easier to add new elements without updating multiple lines.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I can't reply to the above comment, so here is a link to my in-thread reply. https://github.com/kubeflow/website/pull/3693/files#r1521923323

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. SGTM

@rimolive
Copy link
Member

/lgtm

@xujinheng
Copy link
Member

/verify-owners
/lgtm

@kuizhiqing
Copy link
Member

/lgtm

@liuqi
Copy link
Contributor

liuqi commented Mar 13, 2024

/lgtm

Signed-off-by: Andrey Velichkevich <[email protected]>
@google-oss-prow google-oss-prow bot removed the lgtm label Mar 13, 2024
@andreyvelich
Copy link
Member Author

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.
Screenshot 2024-03-13 at 16 30 04

@andreyvelich
Copy link
Member Author

/hold cancel

@thesuperzapper
Copy link
Member

Thanks for all your work @andreyvelich

/lgtm

@google-oss-prow google-oss-prow bot added the lgtm label Mar 13, 2024
@google-oss-prow google-oss-prow bot merged commit 7d85e6e into kubeflow:master Mar 13, 2024
7 checks passed
@andreyvelich andreyvelich deleted the update-dist-table branch March 13, 2024 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants