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

Clean Up GSoC 2025 Project Formatting #4000

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

thesuperzapper
Copy link
Member

@thesuperzapper thesuperzapper commented Feb 13, 2025

related: kubeflow/community#809

This PR improves the formatting and wording to the various GSoC 2025 projects to make the page readable.

It also removes the "Helm Chart" and "Kubeflow IDE" projects, as these have not been approved by the community at this time, so it would be unfair to have students spend time making proposals.

TIP: I recommend looking at the preview to see what the page looks like:

@google-oss-prow google-oss-prow bot requested a review from akgraner February 13, 2025 23:08
Copy link

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from thesuperzapper. For more information see the Kubernetes Code Review Process.

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

@thesuperzapper
Copy link
Member Author

thesuperzapper commented Feb 13, 2025

@andreyvelich @rareddy please review ASAP so we can get the GSoC 2025 page cleaned up, project mentors can update the page after we merge, now that it is consistent.

See preview site

- [Kale Donation to Kubeflow](https://github.com/kubeflow/community/issues/730)
#### Expected Size of the Project
350 Hours

Copy link
Member

Choose a reason for hiding this comment

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

Can we get confirmation from @StefanoFioravanzo @ederign @juliusvonkohout @kimwnasptd on removing these projects?

Copy link
Member Author

Choose a reason for hiding this comment

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

Just to be clear, we are talking about removing the following projects from the GSoC page, not that we will never do them:

  • "Helm Chart"
  • "Kubeflow IDE"

Also, once we agree as a community about the IDE one, and get a well scoped project for a student, we can add a new project before people start submitting applications.

Copy link
Member

Choose a reason for hiding this comment

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

I plan to resume the IDE WG discussion and discuss the next steps at next Tuesday's meeting. Can we hold off on removing GSoC until then?

Copy link
Member

Choose a reason for hiding this comment

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

I don't get the reason for removing this project. @thesuperzapper I'd appreciate you asked the project's requestors (me and Eder) confirmation and open the discussion before opening a PR that does so.

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 don't get the reason for removing this project. @thesuperzapper I'd appreciate you asked the project's requestors (me and Eder) confirmation and open the discussion before opening a PR that does so.

@StefanoFioravanzo, we actually have been discussing it on the slack channel? Have you been seeing it?

But to summarize the problem, both of these projects aren't technically part of kubeflow, and may not be accepted by the community.

Not to say that they never will be, but right now the IDE working group does not exist and there is no agreement on an official Helm chart.

Trying to use GSoC to force these things through is problematic.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think using GSoC to force a decision is problematic. These sorts of things can often be a good forcing function to make a decision.

@juliusvonkohout
Copy link
Member

juliusvonkohout commented Feb 14, 2025

If you split it up, i could already merge the formatting improvements. For project removal i need to talk to other KSC members in the KSC meeting.

@juliusvonkohout
Copy link
Member

/hold
@thesuperzapper the removal of the projects will probably not be accepted by the KSC.

@thesuperzapper
Copy link
Member Author

/hold @thesuperzapper the removal of the projects will probably not be accepted by the KSC.

@juliusvonkohout I am quite concerned with having GSoC projects for things that are not yet approved.

In either case, any project that we list here needs to be reasonably scoped for a student so we can define if they "succeed", and currently both the "IDE" and "Helm" ones are more community proposals than projects.

However, I am most concerned about the helm chart project, this is a BIG change for Kubeflow, and I have not seen an approved KEP to make an official helm chart distribution.

As a compromise, if a specific component (not platform) wants help making a helm chart, we could add a project for that, but the working group for that component would need to be involved.

@thesuperzapper
Copy link
Member Author

@andreyvelich I thought you were in agreement that we should not have GSoC projects for unapproved proposals.

Has your opinion changed?

@andreyvelich
Copy link
Member

@andreyvelich I thought you were in agreement that we should not have GSoC projects for unapproved proposals.

Has your opinion changed?

No, I still have the same opinion. We discuss it today with @johnugeorge, @juliusvonkohout, and @franciscojavierarceo.
For the Helm Chart my proposal was that student will work on projects, that currently can be deployed in standalone mode, and doesn't require additional dependencies:

Kubeflow Trainer
Kubeflow Katib
Kubeflow Spark Operator
Potentially, Kubeflow Model Registry

Also, student could help us to explore on how we can improve multi-tenancy and auth for KFP and Kubeflow Notebooks to make them work as a micro-service. Which allows end-users to easily switch auth and multi-tenancy in a way they want to use it.

One of the option, is to explore how Argo projects are managing auth and multi-tenancy in their UIs.
Their Helm Charts are stored individually: https://github.com/argoproj/argo-helm/tree/main/charts

@thesuperzapper
Copy link
Member Author

thesuperzapper commented Feb 14, 2025

@andreyvelich I will update the PR to re-add a "helm chart" project with the more specific scope of "standalone component helm charts":

Some questions:

  • Do we have issues on those repos saying what their plan is for a helm chart so I can link them for students to read?
  • Won't we need mentors from each of those components to at least be involved, or it will be challenging for them to succeed?

Also regarding the IDE one, should we just leave it off for now, and allow them to re-add it if/when the IDE proposal gets finalized?

@andreyvelich
Copy link
Member

Do we have issues on those repos saying what their plan is for a helm chart so I can link them for students to read?

Not yet, I hope mentors can drive it. We have one for Kubeflow Trainer: kubeflow/trainer#1197

Won't we need mentors from each of those components to at least be involved, or it will be challenging for them to succeed?

I don't think we need mentors for each projects since student can design re-usable script that work across different projects.

Also regarding the IDE one, should we just leave it off for now, and allow them to re-add it if/when the IDE proposal gets finalized?

I would like to hear @StefanoFioravanzo and @ederign suggestions here.

@StefanoFioravanzo
Copy link
Member

I understand the concern about promoting a project tied to a WG that hasn't been officially approved. Our understanding is that there is no particular objection to finalize the WG proposal, @ederign will bring it up anyway in the next community meeting to push things forward. If we can hold off removing the project proposal until then, I'd appreciate.

@juliusvonkohout
Copy link
Member

juliusvonkohout commented Feb 17, 2025

@andreyvelich I will update the PR to re-add a "helm chart" project with the more specific scope of "standalone component helm charts":

Some questions:

* Do we have issues on those repos saying what their plan is for a helm chart so I can link them for students to read?

* Won't we need mentors from each of those components to at least be involved, or it will be challenging for them to succeed?

Also regarding the IDE one, should we just leave it off for now, and allow them to re-add it if/when the IDE proposal gets finalized?

There was no vote on this yet and different opinions, so maybe separate it out for now if you want to have it merged sooner. Last exchange I saw was more or less the current Helm proposal.

Signed-off-by: Mathew Wicks <[email protected]>
@thesuperzapper
Copy link
Member Author

@andreyvelich in the interest of getting this merged (because the current page is very hard to read), I have re-added the Helm/IDE projects.

As discussed in #4000 (comment) I have scoped the helm project down to making charts for standalone components of kubeflow, rather than the overall kubeflow platform.

I think this should be acceptable to merge now, and we can update/remove projects if things change in future PRs.

Copy link
Member

@andreyvelich andreyvelich left a comment

Choose a reason for hiding this comment

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

I left a few comments.
For me changes looks good, but we need lgtm from other mentors.

* Kubeflow Documentation: [Kubeflow.org](https://www.kubeflow.org/)
* Helm Documentation: Helm.sh
- Work with Kubeflow components maintainers to support the creation of Helm charts for some Standalone Kubeflow components.
- Investigate possible systems to automatically generate or maintain charts based on the existing kustomize manifests.
Copy link
Member

Choose a reason for hiding this comment

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

Should we say design and implement synchronization script between Helm and Kustomize to keep manifests up-to-date?
For example, @ChenYi015 already implemented one script for KFTrainer: https://github.com/kubeflow/trainer/blob/c0b1d7d26e7a7caea1ffd8b3111b79be6de24b78/hack/sync-manifests.sh

Comment on lines +90 to +91
- Pipelines: productionize the [SeaweedFS PoC](https://github.com/kubeflow/manifests/tree/master/contrib/seaweedfs) as secure minio replacement
- Pipelines: isolate artifacts per namespace/profile/user using only one bucket ([`kubeflow/pipelines#4649`](https://github.com/kubeflow/pipelines/issues/4649))
Copy link
Member

@andreyvelich andreyvelich Feb 18, 2025

Choose a reason for hiding this comment

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

Shouldn't this be a separate project since these are very complex tasks ?

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 think the idea is that @juliusvonkohout and myself will only mentor 1-2 of these because there are too many to accept a project for all.

They also have very similar skill requirements, so it's not a big deal, as it lets the students apply to the area they want to focus on.

350 hours
- containers and Kubernetes knowledge
- Helm (especially templating and chart creation)
- Kustomize (not strictly required, but a plus)
Copy link
Member

@andreyvelich andreyvelich Feb 18, 2025

Choose a reason for hiding this comment

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

I think, this skill is a requirement since we should design the sync scripts as well.

#### Mentors:
- Andrey Velichkevich,
- Valentina Rodriguez Sosa
### Project 8: Support JAX and TensorFlow Training Runtimes
Copy link
Member

Choose a reason for hiding this comment

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

---
---

### Project 9: Sidecars for Katib Metrics Collectors
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
### Project 9: Sidecars for Katib Metrics Collectors
### Project 9: Kubernetes-native Sidecars Containers for Katib Metrics Collector

@rareddy
Copy link
Contributor

rareddy commented Feb 18, 2025

/lgtm +1

@juliusvonkohout
Copy link
Member

juliusvonkohout commented Feb 18, 2025

/hold
/ do not merge for anything related to removing or altering the goals of projects without the mentors and or KSC agreeing

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.

7 participants