mpi-operator
mpi-operator copied to clipboard
kubeflow
Donate repo to kubernetes-sigs
TLDR from : #341
There is some renewed interest in moving the mpi-operator to (possibly) kubernetes-sigs, assuming that SIG Apps is willing to sponsor the repo.
The motivation is to encourage non-training users (like HPC) to use and contribute to it, without having to install or learn about kubeflow's training-operator.
-
Most Kubeflow components are "loosely coupled", so the definition of "being part of kubeflow" is mostly about if a Kubeflow Working Group is responsible for it
-
The committers of the mpi-operator can decide where the best home for it is, but being under the Kubeflow brand certainly will bring more attention to the tool
from https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#rules-for-donated-repositories
- [ ] All contributors must have signed the CNCF Individual CLA or CNCF Corporate CLA
- [ ] If (a) contributor(s) have not signed the CLA and could not be reached, a NOTICE file should be added referencing section 7 of the CLA with a list of the developers who could not be reached
- [ ] Licenses of dependencies are acceptable; project owners can ping @caniszczyk for review of third party deps
- [ ] Boilerplate text across all files should attribute copyright as follows: "Copyright <Project Authors>" if no CLA was in place prior to donation
- [ ] Additions of the standard Kubernetes header to code created by the contributors can occur post-transfer, but should ideally occur shortly thereafter.
- [ ] Should contain template files as per the kubernetes-template-project.
- [ ] Kubeflow plan to migrate MPi-Jobs dependencies to the news k8s-sigs/mpi-operator location
After Donation / repo creation under k8s-sigs/mpi-operator we need to :
- [ ] Stabilize the current code under k8s-gis parameters
- [ ] Cut a first release under k8s-sigs
- [ ] Migrate Kubeflow projects to new location
Repo will be sponsored by sig-Apps
Can you add the rationale for the donation in the description?
Also it would be good to add what's the high-level plan for kubeflow to use the kubernetes-sig/mpi-operator in their manifests.
Perhaps this data point is relevant from the Kubeflow User Survey, which shows MPI's position to other technologies used by Kubeflow users.
Step one:
- To the question: Are you ok with donating the repo mpi-operator to kubernetes-sigs, please reply lgtm
From the OWNERS file: @ rongou @terrytangyuan @alculquicondor @carmark @gaocegege @zw0610
Hi there, @kubeflow/project-steering-group will need to see a proposal with the following information. This should also be open for broader community feedback before any decision is made.
- Goals
- Motivation / Rationale
- User Benefit
- Design Proposal, including: -- Alternatives Considered -- Dependencies -- User Impact
- Detailed Design
Hi there, @kubeflow/project-steering-group will need to see a proposal with the following information. This should also be open for broader community feedback before any decision is made.
- Goals
- Motivation / Rationale
- User Benefit
- Design Proposal, including: -- Alternatives Considered -- Dependencies -- User Impact
- Detailed Design
Will work on it, thanks for the check list
The best place to submit is as a PR to the following directory: https://github.com/kubeflow/community/tree/master/proposals
Thank you! Our proposal process is not widely known, but it's important to follow for any proposed changes that include code governance.
lgtm
On Wed, Mar 9, 2022 at 1:22 PM Thea Lamkin @.***> wrote:
The best place to submit is as a PR to the following directory: https://github.com/kubeflow/community/tree/master/proposals
Thank you! Our proposal process is not widely known, but it's important to follow for any proposed changes that include code governance.
— Reply to this email directly, view it on GitHub https://github.com/kubeflow/mpi-operator/issues/459#issuecomment-1063383618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADZLTLZSDONFJ6MGACU4PLU7EJA7ANCNFSM5QKOC5VQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
LGTM. Let's get a formal proposal for final review from @kubeflow/project-steering-group.
em.. I am not sure if WG-training give enough feedbacks on this. mpi-operator is one of the training operator suite. What about others or the universal operator? We need to have a concrete plan for the donation
I also want to highlight that by definition, if a project is donated from Kubeflow to another organization, Kubeflow will no longer have any control over it.
This means there would be a question of what to do with the Kubeflow Working Group which controls that project.
In the case that only one part of a WG is donated, then that WG would continue to exist. (Assuming the community thinks there are enough meaningful things that remain under the WG's control)
In the case that most or all of a WG's code is donated, obviously that WG would be disestablished. In such cases, it may also make sense to create a SIG for users of Kubeflow AND that tool (just like we have for other projects that were developed outside of Kubeflow).
