Proposal: OSM for Project Archive

[phillipgibson]

Signed-off-by: Phill Gibson [email protected]

[caniszczyk]

FYI @cncf/cncf-toc

[caniszczyk]

FYI https://linkerd.io/2023/05/05/welcome-to-linkerd-open-service-mesh-adopters/

[TheFoxAtWork]

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!

[craigbox]

FYI https://linkerd.io/2023/05/05/welcome-to-linkerd-open-service-mesh-adopters/

quite a lot of vendor-non-neutrality in that Linkerd blog post if you ask me

[caishu97]

Signed-off-by: Phill Gibson [email protected]

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?

[craigbox]

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.

[amye]

With more comments on the issue, we'll extend comments here through May 26th at least.

[keithmattix]

Signed-off-by: Phill Gibson [email protected]

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?

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

[caishu97]

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.

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.

[caishu97]

Signed-off-by: Phill Gibson [email protected]

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?

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

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...

[craigbox]

@caishu97: There have certainly been alternative proxy implementations for Istio in the past: see, for example, https://istio.io/latest/blog/2020/mosn-proxy/.

[caishu97]

@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...

[tao12345666333]

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. 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.

[phillipgibson]

@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.

[caishu97]

@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.

@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~

[caishu97]

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 :

• FSM utilizes Flomesh Pipy proxy as a replacement for OSM's Envoy proxy. This enables FSM to achieve lightweight control and data planes, optimizing CPU and memory resources effectively.
• Implemented traffic interception using eBPF-based technology instead of iptables-based traffic interception.
• FSM offers comprehensive north-south traffic management capabilities, including Ingress and Gateway APIs.
• Additionally, it facilitates seamless interconnectivity among multiple clusters and incorporates service discovery functionality.

You are welcome to join and can get support by opening issues on project page : https://github.com/flomesh-io/fsm/issues

[amye]

Archival vote open on the TOC mailing list: https://lists.cncf.io/g/cncf-toc/message/8075

[draychev]

@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! 🥂

[lahabana]

@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.