-
Notifications
You must be signed in to change notification settings - Fork 629
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
Proposal: OSM for Project Archive #1044
Conversation
Signed-off-by: phillipgibson <phillip.gibson@gmail.com>
4094ae5
to
6163504
Compare
FYI @cncf/cncf-toc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll leave this PR open for two weeks to adhere to our public comment period for PRs. We greatly appreciate the project and OSM Team's time and consideration in the decision to self-archive in favor of a collaborative service mesh focus in the ecosystem. Thank you all!
quite a lot of vendor-non-neutrality in that Linkerd blog post if you ask me |
Flomesh team has the willing to continue dev on this project as it's simple and easy to use. A question: is there any guideline for how to continue or fork as new project if the project is archived? |
The OSM team has plans to make Istio "simpler and easier to use" (or at least improve the perception of that area, as we think we've done a lot of good work already!) Would Flomesh be interested in joining the project? @caishu97, please reach out to the me on the Istio Slack. |
With more comments on the issue, we'll extend comments here through May 26th at least. |
From a user perspective, I believe it's better for projects who want to use the OSM codebase to fork and create a separate brand. For Flomesh specifically, since there's a different proxy being used (pipy instead of Envoy) I think a fork is clearer for users |
While we Flomesh 'make service mesh lighter and easy to use', we developed pipy proxy (https://github.com/flomesh-io/pipy) as the replacement for envoy. In most of our test, osm+pipy use about 1/3 memory and about 60% CPU compare to osm+envoy. So if istio is open to other sidecar proxy than envoy. Flomesh certainly has strong willing to join istio and make istio+pipy a lightweight service mesh. |
Yes, Keith. That's what we did currently. We have a fork of osm (https://github.com/flomesh-io/osm-edge) and also submitted PR to upstream osm. As osm is archived, I'd like to understand what's the best practice for our osm fork? Is it common that we rename the fork and continues work on that? It's not only because osm core implementation is good, but also there are some existing users are using osm and our fork... |
@caishu97: There have certainly been alternative proxy implementations for Istio in the past: see, for example, https://istio.io/latest/blog/2020/mosn-proxy/. |
I know MOSN , they are using xds ... xds introduce unnecessary complexity in the over all design...my opinion... |
Yes. We (Apache APISIX) are also trying to use Apache APISIX as a replacement for Envoy in Istio's data plane, bringing users higher performance, lower learning costs, and easier plugin development. We translate the xds protocol of Istio into APISIX configuration through a component called amesh. But it contains some specific Envoy configurations and is not 100% compatible. If the unified data plane API can be promoted, there will be more choices on the data plane for Istio. |
@caishu97 You're welcome to fork the existing OSM repo and provide any updates to the code base for Flomesh. You will be able to own all your workflows with that fork. As mentioned, you can propose an optional data plane for the Istio project, or you can look to move forward with building the Flomesh project. The OSM archival process should not prohibit you from any of those options. You may even want to investigate moving Flomesh into the CNCF as a possibility, but that would be something you would need to work with the CNCF TOC. If there's no major objections, and consumers of OSM building integrations understand their option to fork the repos, we should move forward to closing this request to archive. Thanks. |
Thanks, Phil. It's clear for me. Thank you very much~ |
To whom stilling use osm or has willing to continue on osm, here we build a new service mesh control plane based on osm (https://github.com/flomesh-io/fsm), with some enhancement :
You are welcome to join and can get support by opening issues on project page : https://github.com/flomesh-io/fsm/issues |
Archival vote open on the TOC mailing list: https://lists.cncf.io/g/cncf-toc/message/8075 |
@phillipgibson Thank you for shepherding this project along to this point! @caishu97 Glad to see that our work on OSM has inspired other projects and continues in a way w/ Flomesh. It was a blast building OSM from the ground up, getting it to v1, GA, and through CNCF! 🥂 |
@caishu97 if you are looking for a CNCF mesh that leverages XDS and that may have a more approachable code base than istio maybe kumahq/kuma could be an option? Might be easier than maintaining a fork of a abandoned project. |
The GitHub repository for `osm` (https://github.com/openservicemesh/osm) was archived on 2023-07-11. The most recent release (v1.2.4) was on 2023-04-20 and the most recent commit was on 2023-07-10. Before the repository was archived, the `README` was updated to include the following message: > The OSM project has been officially archived by the CNCF > (cncf/toc#1044). There will be no more new > development on any repo under the OpenServiceMesh organization. This deprecates the formula accordingly.
The GitHub repository for `osm` (https://github.com/openservicemesh/osm) was archived on 2023-07-11. The most recent release (v1.2.4) was on 2023-04-20 and the most recent commit was on 2023-07-10. Before the repository was archived, the `README` was updated to include the following message: > The OSM project has been officially archived by the CNCF > (cncf/toc#1044). There will be no more new > development on any repo under the OpenServiceMesh organization. This deprecates the formula accordingly.
Signed-off-by: Phill Gibson phillipgibson@gmail.com