Adding Gloo Network to distribution & support page #365
Conversation
👷 Deploy Preview for cilium processing.
|
✅ Deploy Preview for cilium ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Lin Sun <[email protected]> Signed-off-by: Lin Sun <[email protected]>
|
Thanks for your submission. It’s great to see more companies adding Cilium to their products! Before we can merge this PR we need to ensure that the distribution meets the criteria laid out for inclusion. There are two aspects to this: upstream contributions to the codebase and community, and conformant distributions. “A distribution with a maintainer who is also a Cilium committer would meet the threshold of meaningful contribution.” The thinking behind this criteria is that if companies want the marketing benefit from being listed on the project website, they should also bear some of the maintenance burden of the project to help ensure it is sustainable over the long term. It looks like Solo is on the way to meeting this requirement with one contributor (Daneyon) who has recently reached reviewer status. Are there other upstream (code and non-code) contributors and contributions you would like to be taken into account? In the long term we hope to have conformance tests to validate the Cilium functionality included in distributions. In the absence of those, it is at the discretion of Cilium maintainers whether a distribution is acceptable. Per the criteria, “End user interviews, project demos, and more can help with this assessment.” We can discuss which approach suits you best here, on zoom, in Slack, or at KubeCon. |
|
Hi @xmulligan Thank you for getting back to me and I apologize for the slow reply!
Yes, we have Daneyon contributing full time to open source Cilium at the moment, we hope he will be able to get maintainer status soon. Daneyon has extensive experience in open source and was a maintainer for other CNCF projects, I'm a little disappointed the maintainer process for Cilium is not as defined well and from your reply and it could take 2-3 years, which is unheard of for a very experienced OS maintainer. We are planning to add additional resource as well in the next weeks. Below is a list of our non code contribution to the Cilium community:
I saw the conformance issue opened! Daneyon and I are committed to help in any way we can with this effort. In the meanwhile, we can do project demos or run cilium tests (for example the connectivity tests from cilium cli) to help with this assessment. Please let me know the next step and I am happy to work with you on this! Thank you again for your consideration of our request! |
|
@linsun what results do you get if you run the existing Cilium connectivity tests against Gloo Network? That would be a useful data point |
|
Hi @lizrice, we have run the cilium connectivity test per your request and uploaded the log from the test. Please let me know if you need anything else, thank you!! |
|
Hi @lizrice wanted to follow up to see if there is any questions regarding the output or if you need any additional info from me. Thanks! |
src/components/pages/enterprise/distributions/distributions.jsx
Outdated
Show resolved
Hide resolved
Signed-off-by: Lin Sun <[email protected]>
|
Hi @lizrice @xmulligan, I've added this to tmr's cilium dev meeting agenda hoping to get some update. |
|
Sorry for the delay on this over the holidays. In my opinion, the work @danehans is doing is sufficient to meet the "meaningful contributions" threshold, and the connectivity test log output demonstrates that Gloo Network has Cilium within it. So I would be in favour of listing Gloo Network for Cilium. The proposed text says that Gloo Network is supported by "the co-creators of Istio". The Istio FAQ says that "The Istio project was started by teams from Google and IBM in partnership with the Envoy team from Lyft". I know that Solo has lots of individuals folks now who worked on Istio from the early days, but it seems misleading for the Cilium website to say that Solo was a co-creator of the Istio project. Could you find a better way to re-word that that wouldn't be in conflict with the way the Istio project present it? |
src/components/pages/enterprise/distributions/distributions.jsx
Outdated
Show resolved
Hide resolved
Signed-off-by: Lin Sun <[email protected]>
|
Hi @lizrice, thanks for getting back and providing some guidance on moving forward with this PR. I agree with your comment about co-creators of Istio, you are right, it is misleading - Solo employs co-creators of Istio currently but when Istio was created they didn't work for Solo. :) I've replaced it with a description for gloo network for cilium. Please let me know if this looks good on your end and okay to move forward with the PR. Thank you so much! |
|
Just an update from Cilium dev meeting today - I brought up this PR, and folks were excited to see the maturity of Cilium with another enterprise provider being added to cilium site. No objection I heard/recorded from the dev meeting. |
|
Hi @lizrice and @xmulligan, just following up to see if you have any other suggestions or if this is good to go? Thank you!! |
|
We do not have agreement amongst the Cilium committers to accept this yet, the conversation is ongoing |
Hi @lizrice and @xmulligan, just following up to get some update on this, what else is needed to get this approved? For reference, CNCF's guideline for a CNCF project website contains: |
|
Hi @linsun Our goal as committers is to guide the technical direction of the project and encourage positive upstream collaboration. With that in mind, here are our current concerns. The main concern that the committers have is whether a company actively marketing against the Cilium project's security should be eligible to market its own product using the Cilium website. The dynamic of marketing the core Cilium project as having a poorer security posture to sell security on top is seen as an unhealthy relationship with the upstream community. There are responsible disclosure mechanisms in the project and if anyone thinks there is a security issue with Cilium, please follow them as outlined here. Specific instances can be seen in this blog and webinar. This talk also has the potential to fall into this category. Constructive upstream collaboration is critical, especially when it comes to security. The secondary concern is in a similar vein about working within the project rather than trying to market a solution to get the project to adopt it. This blog is an instance however we do appreciate how Solo has worked with the project to update the introduction to link to the upstream issues. After the progress with the xds blog, the committers would love to continue to see a collaborative upstream approach. Do you have suggestions on how Solo can start to ameliorate our main concern? |
|
Hi Bill, Thanks for sharing these concerns and documenting them in public. When Cilium was proposed to the CNCF, it was primarily a CNI project. Solo has been actively and positively promoting the Cilium CNI, including but not limited to:
We've also dedicated resources to working positively upstream since early last year and plan to add more resources. We made 960+ contributions to Cilium for the past year, which includes 65 PRs from 8 authors. There's no guideline that says a company has to offer support for everything in a project in order to be listed. We focus on best-of-breed technologies to solve users problems, Cilium CNI is one part of that stack, but Cilium service mesh is not. (Cilium service mesh is likewise not supported by the large cloud vendors who offer Cilium CNI as part of their hosted Kubernetes solution.) This perspective doesn’t make us a bad player and we should not be excluded from the community. Honest criticism and discussion is part and parcel of healthy upstream collaboration. Regarding your first concern, there was quite some confusion in the market around the mutual authentication offered by Cilium and if it is mTLS, as Nick and this KubeCon panel pointed out. Christian tried to clarify the confusion in the market where mutual authentication is not exactly mTLS and provide his perspective on this to clear the confusion. We think it's a security limitation which is already [recorded in GitHub](cilium/cilium#28986) — not a vulnerability — else we would of course have followed the guidelines to report it. With respect to your second concern, we are committed to work within the project. Our recent participation and work in support of IPv6, Cilium xDS adapter and xDS for state synchronization CFP have demonstrated that. Given all of our contributions to Cilium, please reconsider your decision to have Gloo Network listed as a Cilium CNI provider on cilium.io. If not, please provide any guidance on what else we should do. Thank you! |
|
Hi Bill and Liz, Could you please give a status update on this issue? Is it now ready to be merged? Thanks |
|
We appreciate all of the work that Solo has been doing to improve and market different parts of the Cilium project. We have also been closely monitoring your engagement with the upstream community and overall approach to the project. It is disheartening to continue to see Solo actively marketing against the security of the upstream project. In Solo's latest datasheet, it says "Cilium can present issues due to its mutual authentication approach for Kubernetes workloads, leading to potential security vulnerabilities." Additionally, the KubeCon EU talk Comparing Sidecar-Less Service Mesh from Cilium and Istio further repeated the poor security/architecture messaging (around 29:00). If you would be willing, we'd like to engage in discussion about how we can resolve such conflicts in a mutually beneficial manner for the best of the Cilium community. |
|
I'd like to remind folks here of the policy: https://github.com/cncf/foundation/blob/main/website-guidelines.md "...It’s OK to have different categories of support offered. Simple vetting by the project is needed to ensure that all companies listed really can provide the support promised. Projects are welcome to outsource this vetting to CNCF staff if it becomes a burden." I think the keyword here is SIMPLE vetting that is pretty objective, similar to what is done in the KCSP program or https://prometheus.io/support-training/ |
|
Getting the vetting done hasn't been a problem - the reason we haven't committed this change is that several committers objected to using the project website to promote a company while that company is actively marketing against the project, and (as Bill mentioned above) there is still a glaring example of that in the current Solo datasheet. That said, these days there are also lots of good examples of Solo content that is supportive (e.g. the Cilium CNI course in the Solo Academy). @craigbox do you think it's possible to get the datasheet fixed so that this objection goes away? |
Hey Cilium community,
We would like to propose to add our Gloo Network product to the distribution & support page on cilium.io. Gloo Network provides enterprise Cilium CNI that is integrated with Istio, maintained by our team. Please let us know if Gloo Network could be added to this page or not. Thanks so much for the consideration!