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
Argo proposal for CNCF Incubation #299
Conversation
RFC @cncf/toc I believe this should be presented to SIG App Delivery first before it goes to the TOC. |
@caniszczyk Thank you, will schedule a presentation. |
Presentation: Argo Proposal for CNCF Incubation on October 9th. |
cncf/tag-app-delivery#18 is the SIG App-Delivery review, waiting on review from @AloisReitbauer + App-Delivery group |
This was reviewed by the CNCF SIG App Delivery: https://docs.google.com/document/d/1rhL9CIInKAArIVpLiabiSuNCi14sSUD_0sDUbjEWPw0/edit# It's now up for the @cncf/toc to decide if you want to move it to a vote, here are the comments from CNCF SIG App Delivery:
|
I'm picking this up to evaluate from a TOC perspective. |
Argo checks out from both a technical and open source perspective. I'm happy to sponsor. I think it'd be a great project to have in the CNCF and the community would benefit. It's already a well adopted project. I only have one question. Argo is a suite of 4 projects that can be used independently with Argo Workflows being the most popular. We generally have one project that gets accepted into the CNCF (housed in single repo) with perhaps several subprojects. In this case, are we looking to accept Argo Workflows as the main project and Events, CD, Rollouts as subprojects or is the whole suite the project we accept? If we accept the suite then what happens if other projects come under the Argo umbrella? Are they considered sub projects? @cncf/toc - do you have thoughts around this? @xiang90 - would love to hear your thoughts since I think you've also looked into Argo. |
@michelleN thank you for sponsoring the project! Argo is an application delivery platform for Kubernetes. While components can be used individually, the trend is to use a combination of components to manage jobs and applications on Kubernetes. We've discussed the governance model for the project with SIG App Delivery. In particular, conducting a joint review of any new projects for inclusion under the Argo umbrella to ensure consistency of purpose and avoid project creep. |
@edlee2121 I think that is a good path forward. Is that documented somewhere? |
@michelleN We will update the governance doc if/when Argo is accepted. |
Hey @edlee2121 - I'd really love to see what the governance would look like. Who would do the joint review? Would future projects under the Argo umbrella be considered subprojects or will there be an incubator type process? I just want to get a clear understanding of this before we vote. |
@edlee2121 if you're looking for an example of a governance policy that you can add projects, see envoy which has done subprojects https://github.com/envoyproxy/envoy/blob/master/GOVERNANCE.md#adding-new-projects-to-the-envoyproxy-github-organization - |
@caniszczyk Thank you. This looks like a good mechanism that we can adopt as well. We would also submit a proposal to SIG App Delivery, similar to what we just did for the initial Argo proposal. So the joint review would be done by the Argo Project and SIG App Delivery. New projects would have to fit within the scope of the Argo Project. Anything too big or too different would be an entirely new submission to CNCF and would go through the standard sandbox/incubation process. @michelleN Does this answer your questions? Please let me know if you would like to have a quick chat by phone/zoom. Thank you! |
Currently, the SIG serves as a set of domain experts that help review projects. They are not a decision making body so the joint review proposal is a completely new process and not in the scope of the SIG. Also, projects should be able to govern themselves. If we can clearly articulate the scope, then I don't think a decision from the SIG or a SIG review of an additional tool in Argo would be necessary as long as the new project is considered a sub project until it gains a level of maturity matching incubation requirements. At which point, I'd be comfortable with the Argo project calling it a top level project. I want make sure Argo can act independently and govern the project independently but I also want to make sure we're giving the community all the right signals. This is the scope I'm drawing from the project: Happy to get on a call. Feel free to ping me on the cncf slack. |
Yes, agreed that top level Argo projects should meet CNCF incubation requirements. @michelleN Updated the PR/proposal as discussed. |
Thanks @edlee2121 Just to update everyone on what we discussed: The Argo project will be the set of tools described in the proposal. If additional projects are added to the project, they will be sub-projects and labeled appropriately. The sub-projects may become top level projects when it meetings CNCF incubation criteria and the project maintainers will add it to the top level at their discretion. To ensure there isn't scope creep, @edlee2121 updated the description of the project. Although I think we should consider replacing As the SIG App Delivery chairs mentioned, the project is heavily driven by Intuit. They have a healthy number of maintainers and contributors from outside the company though so this really should not be a blocker for getting into incubation. Part of a project graduating in the CNCF means that it will be around for a while, that end users can trust the project and that if a set of maintainers from one company walks away then the project won't fall apart. I'd ask the Argo maintainers just think about that during the incubation period and ensure the governance allows for longevity of the project. The Argo projects wants to take in and merge the Flux project in the future. I think this is a great step forward and they should follow the process outlined above to do that. @resouer @AloisReitbauer @bryanl -- please feel free to provide any feedback here and thank you for your work. @amye - Unless there are any objections from the TOC or SIG chairs to the agreements above, please help us kick off a vote for this project EOD. Thank you so much for you patience @edlee2121 and all the Argo folks. |
Thank you everyone for your time and consideration! |
Welcome Argo! Binding: 8/10 |
Chris, I see 9 names not 8 🙂
Ed
…________________________________
From: Chris Aniszczyk <notifications@github.com>
Sent: Tuesday, April 7, 2020 9:33 AM
To: cncf/toc <toc@noreply.github.com>
Cc: Lee, Edward <Edward_Lee@intuit.com>; Mention <mention@noreply.github.com>
Subject: Re: [cncf/toc] Argo proposal for CNCF Incubation (#299)
This email is from an external sender.
Welcome Argo!
Binding: 8/10
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/4401
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/4417
Xiang Li: https://lists.cncf.io/g/cncf-toc/message/4425
Matt Klein: https://lists.cncf.io/g/cncf-toc/message/4439
Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/4441
Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/4446
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/4448
Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/4451
Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/4411
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#299 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADGHCNTMFD6PXONAJEFHXPDRLNIURANCNFSM4IZ37VDQ>.
|
That was my error, Brendan Burns was a late add from an out-of-thread reply. |
This is a proposal for making Argo a part of CNCF Incubation.
We've discussed the project with several TOC members but have not schedule it for a TOC meeting yet.
Please let us know if anything is unclear or additional information is needed.
Kind Regards