Date   

Re: [VOTE] etcd project proposal (incubation)

Eichten, Daniel
 

+1 (non-binding)

 

From: <cncf-toc@...> on behalf of Alex Chircop <alex.chircop@...>
Date: Tuesday, 21. August 2018 at 17:13
To: Chris Aniszczyk <caniszczyk@...>, CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] etcd project proposal (incubation)

 

+1 (non-binding)

 

From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
Date: Tuesday, 21 August 2018 at 15:57
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] etcd project proposal (incubation)

 

The etcd project is being proposed as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC: https://github.com/coreos/etcd

 

etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory and mainly used as a separate coordination service for other distributed systems like Kubernetes. It is used by a variety organizations and projects: https://github.com/coreos/etcd/blob/master/Documentation/production-users.md


Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/143


Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719

adidas AG, Adi-Dassler-Strasse 1, 91074 Herzogenaurach, Germany
Amtsgericht Fürth, HRB 3868
Chairman of Supervisory Board: Igor Landau
Chief Executive Officer: Kasper Rorsted
Further Executive Board Members: Roland Auschel, Harm Ohlmeyer, Karen Parkin, Eric Liedtke, Gil Steyaert

This e-mail or any attachments may contain confidential or privileged information. Unless you are the intended recipient, you may not disclose, copy or use any information herein. If you have received this e-mail message in error, please notify the sender immediately by reply and delete the e-mail from your system.


Re: [VOTE] etcd project proposal (incubation)

Alex Chircop
 

+1 (non-binding)

 

From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
Date: Tuesday, 21 August 2018 at 15:57
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] etcd project proposal (incubation)

 

The etcd project is being proposed as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC: https://github.com/coreos/etcd

 

etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory and mainly used as a separate coordination service for other distributed systems like Kubernetes. It is used by a variety organizations and projects: https://github.com/coreos/etcd/blob/master/Documentation/production-users.md


Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/143


Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


Re: [VOTE] etcd project proposal (incubation)

Doug Davis <dug@...>
 

+1 non-binding


thanks
-Doug
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog

"Chris Aniszczyk" ---08/21/2018 10:57:48 AM---The etcd project is being proposed as an INCUBATION level CNCF project, sponsored by Brian Grant fro

From: "Chris Aniszczyk" <caniszczyk@...>
To: CNCF TOC <cncf-toc@...>
Date: 08/21/2018 10:57 AM
Subject: [cncf-toc] [VOTE] etcd project proposal (incubation)
Sent by: cncf-toc@...





The etcd project is being proposed as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC: https://github.com/coreos/etcd

etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory and mainly used as a separate coordination service for other distributed systems like Kubernetes. It is used by a variety organizations and projects: https://github.com/coreos/etcd/blob/master/Documentation/production-users.md

Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/143

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719




Re: [VOTE] etcd project proposal (incubation)

subhendu.ghosh@...
 

+1 (non-binding)

 

From: cncf-toc@... [mailto:cncf-toc@...] On Behalf Of Chris Aniszczyk
Sent: Tuesday, August 21, 2018 10:58 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] etcd project proposal (incubation)

 

The etcd project is being proposed as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC: https://github.com/coreos/etcd

 

etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory and mainly used as a separate coordination service for other distributed systems like Kubernetes. It is used by a variety organizations and projects: https://github.com/coreos/etcd/blob/master/Documentation/production-users.md


Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/143


Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.


Re: [VOTE] etcd project proposal (incubation)

Arun Gupta
 

+1 (non-binding)

On Tue, Aug 21, 2018 at 7:57 AM Chris Aniszczyk <caniszczyk@...> wrote:
The etcd project is being proposed as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC: https://github.com/coreos/etcd

etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory and mainly used as a separate coordination service for other distributed systems like Kubernetes. It is used by a variety organizations and projects: https://github.com/coreos/etcd/blob/master/Documentation/production-users.md

Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/143

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719




[VOTE] etcd project proposal (incubation)

Chris Aniszczyk
 

The etcd project is being proposed as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC: https://github.com/coreos/etcd

etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory and mainly used as a separate coordination service for other distributed systems like Kubernetes. It is used by a variety organizations and projects: https://github.com/coreos/etcd/blob/master/Documentation/production-users.md

Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/143

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


TOC Agenda for 8/21/2018

Chris Aniszczyk
 

Here's the agenda deck:

We plan to cover a buildpacks spec project proposal, a proposal to move rook to incubation, fluentd asking for a graduation vote, a new WG proposed around security along with a backlog of reviews to discuss.

See everyone soon!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: apologies

Sam Lambert <samlambert@...>
 

I won't be able to make tomorrow either. Sorry folks.

On Mon, Aug 20, 2018 at 3:44 AM, alexis richardson <alexis@...> wrote:
I shall be on a plane during tomorrow's TOC call.

Ken -- will you be on and can you chair please?





apologies

alexis richardson
 

I shall be on a plane during tomorrow's TOC call.

Ken -- will you be on and can you chair please?


CNCF Chinese style guide

Dan Kohn <dan@...>
 

After our success with a crowdsourced effort to translate the Cloud Native Definition, we wanted to kick off a similar effort on a Chinese style guide for cloud native terms. We want to thank KubeCon + CloudNativeCon Shanghai co-chair Janet Kuo, who began this work by correcting some of the translations we received from a service.

You can see all of the sessions for Shanghai (which will be Nov. 13-15) in English and Chinese. Please make suggestions for improved translations in the style guide, and we will then correct the schedule and share this guide will the interpreters (note that all keynotes and sessions in Shanghai will feature simultaneous interpretation).

If you'd like to discuss this guide more generally, please do it on k8s-chinese-translators@lists.cncf.io.
--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com


Re: Graduation review for Fluentd

Eduardo Silva
 

Hi ToC and Contributors, 

Fluentd project is really interested into get your feedback about our graduation request:


any feedback is appreciated.

regards, 


On Tue, Jan 16, 2018 at 10:30 PM Brian Grant via Lists.Cncf.Io <briangrant=google.com@...> wrote:
The application specifically addressed the graduation criteria, which was helpful.

I posted some links to some stats relating to project health and contributor diversity. The incubation criteria also apply at graduation: 


I think there's an opportunity for help from TOC contributors with these types of reviews, to pre-review the information provided, ask questions about project health and adoption, whether the projects are getting what they need from CNCF, and whatever else we feel is important.

On Fri, Jan 5, 2018 at 7:51 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
It's on queue to discuss at the next TOC meeting in terms of how we are going to handle the process.

We also have some project proposals in flight that we are tackling.

On Fri, Jan 5, 2018 at 9:49 AM, Eduardo Silva via cncf-toc <cncf-toc@...> wrote:
Hello everyone, 

is there any update about when graduation reviews will happen ?

best, 

On Fri, Dec 1, 2017 at 1:44 PM, Eduardo Silva <eduardo@...> wrote:
thanks Chris for the update. 

As usual please let us know if TOC requires any additional info

best

On Fri, Dec 1, 2017 at 1:39 PM, Chris Aniszczyk <caniszczyk@...> wrote:
Hey Eduardo, the current feeling within the TOC was that everyone was slammed with the conference coming up next week to do formal reviews.

We plan to discuss the graduation review process at the TOC F2F next week and make a decision.

Thanks.

On Fri, Dec 1, 2017 at 7:32 PM, Eduardo Silva via cncf-toc <cncf-toc@...> wrote:
Hello TOC!, 

Fluentd team have sent a PR with the required information for the graduation review of the project, would you please take a look at it and share some feedback ? 

https://github.com/cncf/toc/pull/69

thanks, 

--
Eduardo Silva
Open Source, Treasure Data
http://www.treasuredata.com/opensource

 

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Eduardo Silva
Open Source, Treasure Data
http://www.treasuredata.com/opensource

 



--
Eduardo Silva
Open Source, Treasure Data
http://www.treasuredata.com/opensource

 

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Eduardo Silva
Open Source, Treasure Data
http://www.treasuredata.com/opensource

 


Re: RSocket Followup (post TOC meeting)

alexis richardson
 

Tim,

Thanks! I think we would all be interested in your reasons for liking gRPC.

alexis



On Sat, Aug 11, 2018 at 4:07 AM, via Lists.Cncf.Io
<tim=netflix.com@...> wrote:
I see Kailash CCd me into the thread given Netflix's experience with both
RSocket and gRPC.

It should be noted that at this point (as of roughly 6 months ago) all use
of RSocket has been completely abandoned at Netflix in favor of gRPC, and
the only team that build an app with RSocket chose to rewrite their app
leveraging gRPC and the associated components. gRPC has also allowed us to
build (and easily integrate) a suite of resilience-oriented tech, such as
our Adaptive Concurrency Limiters
(https://medium.com/@NetflixTechBlog/performance-under-load-3e6fa9a60581)
that solve the retry-storm problem with no additional client-side complexity
or configuration.

While I am not best-suited to address statements on the matrix of specific
points being discussed, if anyone has questions, I can speak to the many
usability/ergonomic, simplicity, community, and
development-velocity/productivity related reasons that ultimately led
Netflix (both the Platform team, and the users) to choose gRPC as our
microservice RPC foundation.

Tim Bozarth
Director, Platform @ Netflix


On Thu, Aug 9, 2018 at 10:52 AM, Kailash Sethuraman <hsaliak@...>
wrote:

Adding Tim Bozarth from Netflix, who's had some practical experience
working with both gRPC and RSocket. Full thread here:
https://lists.cncf.io/g/cncf-toc/topic/rsocket_followup_post_toc/24221841

+1 to a public feature comparison table.
In such a table, it will be good to figure out how to do justice to
deliberate design choices and the tradeoffs. For example, broker vs
no-broker, or choosing to base on top of http/2. Projects have valid reasons
to go one way or another, and those considerations are very beneficial for
the user to understand.


FYI : I saw a few minor misconceptions for gRPC and I have called out a
few that stood out.:
- binary - must be wrapped in protobuf. This is not necessary, though
offers a convenience. There are other formats (eg: flatbuffers) that
support gRPC service generation.
- max payload size is confiugrable
- full duplex -- not sure what this means. gRPC supports bi directional
streams.
- IPC is not protobuf only.



On Wed, Aug 8, 2018 at 3:45 PM <colin@...> wrote:

Reading through the responses, imo this speaks to a need for a public
project feature comparison I mentioned elsewhere in this thread
(https://lists.cncf.io/g/cncf-toc/message/2192).


Re: RSocket Followup (post TOC meeting)

Timothy Bozarth <tim@...>
 

I see Kailash CCd me into the thread given Netflix's experience with both RSocket and gRPC.  

It should be noted that at this point (as of roughly 6 months ago) all use of RSocket has been completely abandoned at Netflix in favor of gRPC, and the only team that build an app with RSocket chose to rewrite their app leveraging gRPC and the associated components.  gRPC has also allowed us to build (and easily integrate) a suite of resilience-oriented tech, such as our Adaptive Concurrency Limiters (https://medium.com/@NetflixTechBlog/performance-under-load-3e6fa9a60581) that solve the retry-storm problem with no additional client-side complexity or configuration.

While I am not best-suited to address statements on the matrix of specific points being discussed, if anyone has questions, I can speak to the many usability/ergonomic, simplicity, community, and development-velocity/productivity related reasons that ultimately led Netflix (both the Platform team, and the users) to choose gRPC as our microservice RPC foundation.

Tim Bozarth
Director, Platform @ Netflix


On Thu, Aug 9, 2018 at 10:52 AM, Kailash Sethuraman <hsaliak@...> wrote:
Adding Tim Bozarth from Netflix, who's had some practical experience working with both gRPC and RSocket. Full thread here: https://lists.cncf.io/g/cncf-toc/topic/rsocket_followup_post_toc/24221841

+1 to a public feature comparison table. 
In such a table, it will be good to figure out how to do justice to deliberate design choices and the tradeoffs. For example, broker vs no-broker, or choosing to base on top of http/2. Projects have valid reasons to go one way or another, and those considerations are very beneficial for the user to understand.


FYI : I saw a few minor misconceptions for gRPC and I have called out a few that stood out.:
- binary - must be wrapped in protobuf. This is not necessary, though offers a convenience. There are other formats  (eg: flatbuffers) that support gRPC service generation.
- max payload size is confiugrable
- full duplex -- not sure what this means. gRPC supports bi directional streams.
- IPC  is not protobuf only. 



On Wed, Aug 8, 2018 at 3:45 PM <colin@...> wrote:
Reading through the responses, imo this speaks to a need for a public project feature comparison I mentioned elsewhere in this thread (https://lists.cncf.io/g/cncf-toc/message/2192).



Re: Question on sandbox projects

Dan Kohn <dan@...>
 

On Fri, Aug 10, 2018 at 9:10 PM, Brandon Philips <bphilips@...> wrote:
Maybe prefix things intead of postfix things to get the ordering right? Some tools sort () and [] after letters and numbers. Give it a shot?


If we changed the order of the projects, all the remaining submissions would be corrupted, due to a limitation of the tool we are using. 
 
FWIW, the over promotion of sandbox projects was raised at the GB meeting as well and I share the concern about the current format.

CNCF staff has gotten clear feedback from both the TOC and the GB to minimize the marketing of the sandbox projects. We will change the format of this form for future events, but can't do so in the remaining 48 hours the CFP is open.
--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com




Re: Question on sandbox projects

Brandon Philips <bphilips@...>
 

Maybe prefix things intead of postfix things to get the ordering right? Some tools sort () and [] after letters and numbers. Give it a shot?

FWIW, the over promotion of sandbox projects was raised at the GB meeting as well and I share the concern about the current format.

Brandon

On Thu, Aug 9, 2018 at 2:06 PM Chris Aniszczyk <caniszczyk@...> wrote:
FYI this is the best we can do, based on the day the data is pulled within the CFP program (it's why Helm is at the bottom instead of alphabetized currently)

If we reorder them, then, for example, anything that has been submitted as Container Networking thus far will essentially lose its data:

We will see if we can improve things in 2019 with the CFP system, thanks for the feedback.

On Thu, Aug 9, 2018 at 3:58 PM, Chris Aniszczyk <caniszczyk@...> wrote:
and of course I posted the wrong screenshot sigh: 




On Thu, Aug 9, 2018 at 3:57 PM, Chris Aniszczyk <caniszczyk@...> wrote:
At the moment, we are limited to what the CFP tool is capable of doing, so we only have a list.

We have updated the list of projects to label their relative maturity level in the CFP system.

For future CFPs, we will see if we can do what you have suggested.

On Thu, Aug 9, 2018 at 3:53 PM, Quinton Hoole <quinton.hoole@...> wrote:
OK, I’m suggesting the opposite – three clearly separate lists – graduated, incubating, sandbox

If I’m the only one who feel strongly on this I’m happy to step down off my soapbox.  But I remember other TOC members having similarly strong feelings on the matter.  Brian Cantril, Camille and Alexis come to mind?

Q

From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
Date: Thursday, August 9, 2018 at 13:28
To: Quinton Hoole <quinton.hoole@...>
Cc: Luis Pabon <luis@...>, CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] Question on sandbox projects

We can annotate each listing with the project maturity level, that's my proposed solution moving forward.

On Thu, Aug 9, 2018 at 3:26 PM, Quinton Hoole <quinton.hoole@...> wrote:
This topic has already come up several times in the ToC.  We explicitly decided that a very clear distinction should always be drawn between sandbox, incubation and graduated projects in external-facing communication.  It doesn’t sound like an alphabetical list mixing all of the projects together meets that goal.

Extract from sandbox.md, which I think needs to be strengthened to meet the above goals.

Some key points:

  • Sandbox projects will be listed separately from other CNCF projects (cncf.io/sandbox)
  • They will not be prominently listed at our events or issued a press release
Quinton


From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
Date: Thursday, August 9, 2018 at 13:18
To: Luis Pabon <luis@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] Question on sandbox projects

I don't see an issue with listing the projects in alphabetic order outside that it should be a series of checkboxes instead of radio buttons (we will fix that soon).

The TOC list is meant for technical discussions so if you have something you'd like to change about the CFP form, please email events@... for suggestions and we can have a discussion there.

Thanks.

On Thu, Aug 9, 2018 at 3:00 PM, Luis Pabon <luis@...> wrote:
Correct.

On Thu, Aug 9, 2018 at 12:35 PM, Chris Aniszczyk <caniszczyk@...> wrote:
This is a question more for CNCF staff based on the marketing expectations of sandbox projects:

I'm assuming you mean the alphabetical list of CNCF projects?

On Thu, Aug 9, 2018 at 11:30 AM, Luis Pab?n <luis@...> wrote:
Hi all,
  While creating a CFP for Kubecon/Seattle I noticed that sandbox projects get first level choices in the Kubecon CFP. Does this apply to any sandbox project? Will the CNCF continue with this model if we have many sandbox projects?

Regards,

- Luis




--
Chris Aniszczyk (@cra) | +1-512-961-6719




--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Chris Aniszczyk (@cra) | +1-512-961-6719




--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: RSocket Followup (post TOC meeting)

Ben Hale <bhale@...>
 

In addition, Pivotal's interest in RSocket extends beyond the Java implementation and we're specifically interested in JavaScript and Go. For us to be comfortable, we'd ensure reliable interoperability before we took anything to market with those implementations. Contributing to the TCK and extensive cross implementation testing would be efforts we'd contribute to.


-Ben

On Aug 10, 2018, at 12:54, Robert Roeser <robert@...> wrote:

Hi Alexis,

How much interoperability testing have you done? Especially in the multi hop multi implementation cases
There are internal tests using RSocket with the different implementations and they interoperate – have done tests where C++ calls Java which calls a service in a browser tab (browser acts like microservice), etc. The spec has been fleshed as people worked on the different versions. The TCK is on the road map to be worked on again, we just need to figure out where to host these tests in public.

Cheers,
Robert


From: Alexis Richardson <alexis@...>
Date: Wednesday, August 8, 2018 at 2:41 PM
To: Robert Roeser <robert@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Chris Aniszczyk <caniszczyk@...>, "stevegury@..." <stevegury@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)

How much interoperability testing have you done? Especially in the multi hop multi implementation cases

On Wed, 8 Aug 2018, 22:08 Robert Roeser, <robert@...> wrote:
+stevegury@...

Hi,

Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions

Thanks,
Robert Roeser

Rsocket team, key questions for me are:

- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- RSocket is essentially distributed RxJava or ReactiveStreams

- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.

- RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
- The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
- Support for ReactiveStreams request n style flow control across a binary boundary
- Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
- This application level back-pressure is composeable across services
- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic to other services that have capacity.
- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters

- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started - this is beneficial in error conditions because it will be prevent extra/wasteful processing.

- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
- All interactions are modeled as asynchronous streams with optimizations for the different interaction models
- Request/reply - bi-directional stream of one to one
- Fire/Forget - unidirectional stream of one
- Request/Stream - bidirectional stream of one to many
- Request/Channel - bidirectional stream of many to many

- RSocket supports metadata push which you can use to push metadata associated with a connection.

- RSocket can support many thousands of concurrent streams on a single host

- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern. For instance, this lets a developer work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.

- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple layers, rather than being tied to HTTP/2

- NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something like NATs

- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.

- is rsocket more of a lib or a "product'
RSocket is a library for network communication like `javax.net` or gRPC. Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required. An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.

- what's the Go story?
We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.

From: Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)

Colin, your feedback is essential, please do share

Rsocket team, key questions for me are:

- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- is rsocket more of a lib or a "product'
- what's the Go story?


On Tue, 7 Aug 2018, 17:04 Chris Aniszczyk, <caniszczyk@...> wrote:
https://github.com/rsocket

I just wanted to move this discussion to the mailing list as there was some questions that weren't answered and I know that Colin had some feedback on the project comparisons (rsocket vs nats vs grpc)

Also Alexis Richardson from the TOC is OK to sponsor this effort into the Sandbox, so if anyone else is interested in sponsoring, please let me know.

Feel free to continue the discussion here.


--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: RSocket Followup (post TOC meeting)

Robert Roeser <robert@...>
 

Hi Alexis,

 

How much interoperability testing have you done?  Especially in the multi hop multi implementation cases

There are internal tests using RSocket with the different implementations and they interoperate – have done tests where C++ calls Java which calls a service in a browser tab (browser acts like microservice), etc. The spec has been fleshed as people worked on the different versions. The TCK is on the road map to be worked on again, we just need to figure out where to host these tests in public.

 

Cheers,

Robert

 

 

From: Alexis Richardson <alexis@...>
Date: Wednesday, August 8, 2018 at 2:41 PM
To: Robert Roeser <robert@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Chris Aniszczyk <caniszczyk@...>, "stevegury@..." <stevegury@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)

 

How much interoperability testing have you done?  Especially in the multi hop multi implementation cases 

 

On Wed, 8 Aug 2018, 22:08 Robert Roeser, <robert@...> wrote:

+stevegury@...

 

Hi,

 

Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions

 

Thanks,

Robert Roeser

 

Rsocket team, key questions for me are:

 

- what are main differences/USPs Vs prior art (nats, grpc, 0mq)

  - RSocket is essentially distributed RxJava or ReactiveStreams

 

- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.

 

    - RSocket complements ReactiveStreams  - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)

- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.

 - The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.

- Support for ReactiveStreams request n style flow control across a binary boundary

- Request n works by a stream consumer sending the producer the number of items it wants to consume.  In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.

 - This application level back-pressure is composeable across services

- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic to other services that have capacity.

- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters

 

- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started -  this is beneficial in error conditions because it will be prevent extra/wasteful processing.

 

- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure

    - All interactions are modeled as asynchronous streams with optimizations for the different interaction models

        - Request/reply - bi-directional stream of one to one

        - Fire/Forget - unidirectional stream of one

        - Request/Stream - bidirectional stream of one to many

        - Request/Channel - bidirectional stream of many to many

 

- RSocket supports metadata push which you can use to push metadata associated with a connection.

 

- RSocket can support many thousands of concurrent streams on a single host

 

- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern.  For instance, this lets a developer work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.

 

- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection.  RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple layers, rather than being tied to HTTP/2

 

-  NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something like NATs

 

- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.

 

- is rsocket more of a lib or a "product'

RSocket is a library for network communication like `javax.net` or gRPC.  Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required.  An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.

 

- what's the Go story?

We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.

 

From: Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)

 

Colin, your feedback is essential, please do share 

 

Rsocket team, key questions for me are:

 

- what are main differences/USPs Vs prior art (nats, grpc, 0mq)

- is rsocket more of a lib or a "product'

- what's the Go story?

 

 

On Tue, 7 Aug 2018, 17:04 Chris Aniszczyk, <caniszczyk@...> wrote:

 

I just wanted to move this discussion to the mailing list as there was some questions that weren't answered and I know that Colin had some feedback on the project comparisons (rsocket vs nats vs grpc)

 

Also Alexis Richardson from the TOC is OK to sponsor this effort into the Sandbox, so if anyone else is interested in sponsoring, please let me know.

 

Feel free to continue the discussion here.


 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


Re: RSocket Followup (post TOC meeting)

alexis richardson
 

Go, java, js and c++ would be a convincing portfolio, if interop worked.


On Fri, 10 Aug 2018, 20:56 Ben Hale, <bhale@...> wrote:
In addition, Pivotal's interest in RSocket extends beyond the Java implementation and we're specifically interested in JavaScript and Go.  For us to be comfortable, we'd ensure reliable interoperability before we took anything to market with those implementations.  Contributing to the TCK and extensive cross implementation testing would be efforts we'd contribute to.


-Ben


> On Aug 10, 2018, at 12:54, Robert Roeser <robert@...> wrote:
>
> Hi Alexis,

> How much interoperability testing have you done?  Especially in the multi hop multi implementation cases
> There are internal tests using RSocket with the different implementations and they interoperate – have done tests where C++ calls Java which calls a service in a browser tab (browser acts like microservice), etc. The spec has been fleshed as people worked on the different versions. The TCK is on the road map to be worked on again, we just need to figure out where to host these tests in public.

> Cheers,
> Robert


> From: Alexis Richardson <alexis@...>
> Date: Wednesday, August 8, 2018 at 2:41 PM
> To: Robert Roeser <robert@...>
> Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Chris Aniszczyk <caniszczyk@...>, "stevegury@..." <stevegury@...>
> Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)

> How much interoperability testing have you done?  Especially in the multi hop multi implementation cases

> On Wed, 8 Aug 2018, 22:08 Robert Roeser, <robert@...> wrote:
> +stevegury@...

> Hi,

> Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions

> Thanks,
> Robert Roeser

> Rsocket team, key questions for me are:

> - what are main differences/USPs Vs prior art (nats, grpc, 0mq)
>   - RSocket is essentially distributed RxJava or ReactiveStreams

> - RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.

>     - RSocket complements ReactiveStreams  - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
> - RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
>  - The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
> - Support for ReactiveStreams request n style flow control across a binary boundary
> - Request n works by a stream consumer sending the producer the number of items it wants to consume.  In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
>  - This application level back-pressure is composeable across services
> - Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic to other services that have capacity.
> - Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters

> - RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started -  this is beneficial in error conditions because it will be prevent extra/wasteful processing.

> - Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
>     - All interactions are modeled as asynchronous streams with optimizations for the different interaction models
>         - Request/reply - bi-directional stream of one to one
>         - Fire/Forget - unidirectional stream of one
>         - Request/Stream - bidirectional stream of one to many
>         - Request/Channel - bidirectional stream of many to many

> - RSocket supports metadata push which you can use to push metadata associated with a connection.

> - RSocket can support many thousands of concurrent streams on a single host

> - Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern.  For instance, this lets a developer work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.

> - gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection.  RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple layers, rather than being tied to HTTP/2

> -  NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something like NATs

> - 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.

> - is rsocket more of a lib or a "product'
> RSocket is a library for network communication like `javax.net` or gRPC.  Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required.  An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.

> - what's the Go story?
> We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.

> From: Alexis Richardson <alexis@...>
> Date: Tuesday, August 7, 2018 at 9:14 AM
> To: Chris Aniszczyk <caniszczyk@...>
> Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
> Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)

> Colin, your feedback is essential, please do share

> Rsocket team, key questions for me are:

> - what are main differences/USPs Vs prior art (nats, grpc, 0mq)
> - is rsocket more of a lib or a "product'
> - what's the Go story?


> On Tue, 7 Aug 2018, 17:04 Chris Aniszczyk, <caniszczyk@...> wrote:
> https://github.com/rsocket

> I just wanted to move this discussion to the mailing list as there was some questions that weren't answered and I know that Colin had some feedback on the project comparisons (rsocket vs nats vs grpc)

> Also Alexis Richardson from the TOC is OK to sponsor this effort into the Sandbox, so if anyone else is interested in sponsoring, please let me know.

> Feel free to continue the discussion here.
>

> --
> Chris Aniszczyk (@cra) | +1-512-961-6719


Re: RSocket Followup (post TOC meeting)

Ben Hale <bhale@...>
 

Is mobile the primary use case today?
RSocket’s primary use-case is distributed systems communication. I mentioned the above example as it’s difficult to do that today and you usually need additional components like Socket.io, long-polling, etc, where as with RSocket it is natural. Resumabilty was added for the mobile use-case and today's implementation is warm resumablity where theserver side hasn’t timed out the subscriptions and flushed them. There has been talk to do cold resumabilty where you could have streams that are able to resume when there isn’t a active subscription on the producing side.

Rsocket uses client-slide load balancing to achieve this?
https://github.com/rsocket/rsocket-java/tree/1.0.x/rsocket-load-balancer
You could do it with client-client load balancer, or a middle-ware load-balancer that understands RSocket. Steve Gury can provide more context about load-balancing on a large scale.

OOC, how much work does cancellation save in practice? Presumably it mostly applies to requests that haven't yet been picked up by their consumers.
Depending on what you are doing, it could be lots of work.

RSocket provides Reactive Stream semantics across a process boundary. In Reactive Streams there are three ways to terminate a stream: it completes, it errors, or you cancel it. All streams (including request/response) support cancellation to allow efficient cleanup of responder resources. This is essential with interaction models such as streams and subscriptions - you need it to cleanly signal to stop streaming data where the stream doesn’t complete or error.

An example how how this works could be a stream of data that has 1,000,000 items, and you want to take a 100 items from it. With ReactiveStreams you can ask for 100 items, and then cancel when you receive them. Before RSocket you could only do this in the same process. With RSocket you can do this between services, even across multiple services it you want (A->B->C……->N). If you use a ReactiveStreams library like RXJava, Reactor-core, Akka-streams, Yarl, etc. all this happens automatically. You basically need to write something like this:

```
Payload p = null;
requestStream(p)
.limitRequest(100)
.subscribe(doSomethingInteresting());
```

The developer doesn’t need to concern them with back pressure or cancellation but the implementation will use this to create the behavior the developer wants.


-Ben


Re: RSocket Followup (post TOC meeting)

alexis richardson
 

I'd like to add to Ben's comments that this pattern is implemented in many message brokers which de facto support relays a->b->c. 

The appeal (to me) of rsocket is to make the pattern part of the protocol and remove the requirement for a broker.

However, to then be useful it is critical that multiple implementations exist and interoperate.



On Fri, 10 Aug 2018, 19:36 Ben Hale, <bhale@...> wrote:
> A pretty common way that application flow control is achieved in TCP-based distributed systems is for a message consumer to simply stop reading messages off a TCP connection if it wants the message producer to stop sending messages from the other end.  TCP does all the rest automatically, compliments of sliding windows, receive buffers etc.  If senders and receivers use fairly basic thread pools, back pressure through the system “just works”, in my experience. It sounds like a fairly significant part of Rsocket is an additional protocol to achieve much the same back-pressure-based application flow control?  Other than to support non-TCP transports (like UDP), which I would assume are fairly uncommon, why did you feel it necessary to add an additional layer of application flow control on top of what TCP already provides?

TCP flow control is at the byte level and RSocket is flow control at the message level.  It's often easier to reason at the message level when you build applications because you don't have to guess how many bytes a single message is.  RSocket arbitrages between transport level flow control, and Reactive Streams semantic.

When you have asynchronous applications that don't have thread pools, the back pressure provided by TCP is often broken because the number of bytes in a message doesn't necessarily correspond to how expensive it is to process.  You can have a one megabyte message processed swiftly and a one kilobyte message that is expensive.  Most people already deal with this application-level flow control problem already using circuit breakers, rate limiters, request throttling and bounded thread pools as you mention.  These are all examples of application back pressure but the common limitation is that all cause an error on the client side when capacity is exceeded.  Essentially, you can only find out if you need to back off by attempting first and then failing.  RSocket eliminates this failing attempt because a client will only request a volume _it_ knows it can handle, and then the server will only send that.  This prevents things like retry storms and extra processing while resulting in better tail latency, etc.

To illustrate this, imagine you have three services A streaming to B, B streaming to C. Lets also say that they are streaming data at 25% of the capacity of the TCP buffer.  C slows down with garbage collection, or expensive to process items. With TCP each buffer has to fill up before A (the root generator) slows down and this only happens after messages have been sent. This leads to cascading failures in services: C is going to get messages it can't handle regardless of the TCP back pressure. The typical way to deal with is add circuit breakers, and rate limiting that create errors when they reach a certain capacity. With RSocket you don't need circuit breakers; instead C stops sending requestN requests to B, and B stops sending requestN's A. Everything slows down to the rate that C can handle, and this happens uniquely and individually for each end-client's performance.

Besides application safety, Reactive Stream requestN semantics make it easier for the developer to create applications that scroll over data,  page over data, or  take a finite amount of data from a stream. It's difficult to reason about how many bytes 8 'user profiles' are, but it's very easy to ask for 8.


-Ben




5321 - 5340 of 7562