Date   

Re: RSocket Followup (post TOC meeting)

Quinton Hoole
 

Yes, that’s right.  I’m not sure where the notion that Go doesn’t do async well came from.  In my experience golang does just fine using channels and go routines.

Here’s a fairly useful article for anyone interested in the topic: https://medium.com/@alexyakunin/go-vs-c-part-1-goroutines-vs-async-await-ac909c651c11

On a different note, on the call I asked a question related to application flow control, but we ran out of time before being able to explore it fully.

My question is basically this:

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?

Thanks

Q
   

Quinton Hoole

Technical Vice President

America Research Center

2330 Central Expressway, Santa Clara, CA 95050

Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9

Email: quinton.hoole@...   ID#Q00403160


From: <cncf-toc@...> on behalf of Robert Roeser <robert@...>
Date: Wednesday, August 8, 2018 at 18:00
To: Justin Cormack <justin.cormack@...>, Chris Aniszczyk <caniszczyk@...>
Cc: CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>, Ben Hale <bhale@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)

Hi Justin,

From the go people I talked with we can use go channels for request stream and request channel. For request / response and fire forget people could be a use a go routine. I am not a go expert but understanding is that you could use buffered channels with the RSocket request n semantics effectively.

I was told the interfaces could be idiomatic go.

Thanks,
Robert


From: Justin Cormack <justin.cormack@...>
Sent: Wednesday, August 8, 2018 3:27:23 PM
To: Chris Aniszczyk
Cc: CNCF TOC; Robert Roeser; Ben Hale
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
 
The Go question came up in the call, which is interesting as much of the CNCF ecosystem is currently
Go based, although diversifying. Go is unusual in not supporting async interfaces really, prefering
to do explicit sync threading. The rsocket protocol is just a wire protocol, but I am curious if anyone
has looked at what the programming interface for Go might look like and whether maintaining this
might be an issue.


On Tue, Aug 7, 2018 at 5:04 PM, 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)

Robert Roeser <robert@...>
 

Hi Justin,

From the go people I talked with we can use go channels for request stream and request channel. For request / response and fire forget people could be a use a go routine. I am not a go expert but understanding is that you could use buffered channels with the RSocket request n semantics effectively.

I was told the interfaces could be idiomatic go.

Thanks,
Robert


From: Justin Cormack <justin.cormack@...>
Sent: Wednesday, August 8, 2018 3:27:23 PM
To: Chris Aniszczyk
Cc: CNCF TOC; Robert Roeser; Ben Hale
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
 
The Go question came up in the call, which is interesting as much of the CNCF ecosystem is currently
Go based, although diversifying. Go is unusual in not supporting async interfaces really, prefering
to do explicit sync threading. The rsocket protocol is just a wire protocol, but I am curious if anyone
has looked at what the programming interface for Go might look like and whether maintaining this
might be an issue.


On Tue, Aug 7, 2018 at 5:04 PM, 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)

colin@...
 

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)

Justin Cormack
 

The Go question came up in the call, which is interesting as much of the CNCF ecosystem is currently
Go based, although diversifying. Go is unusual in not supporting async interfaces really, prefering
to do explicit sync threading. The rsocket protocol is just a wire protocol, but I am curious if anyone
has looked at what the programming interface for Go might look like and whether maintaining this
might be an issue.


On Tue, Aug 7, 2018 at 5:04 PM, 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
 

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)

Robert Roeser <robert@...>
 

+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: RFC: etcd project proposal (incubation)

Quinton Hoole
 

The proposal looks good.  I’m fully in support.

Q

Quinton Hoole

Technical Vice President

America Research Center

2330 Central Expressway, Santa Clara, CA 95050

Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9

Email: quinton.hoole@...   ID#Q00403160


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

Just a heads up, the etcd community published their incubation project proposal:

I'd like to invite the TOC and wider community to review it for a week or so before we call for a formal vote in the coming weeks.

Thanks!

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


RFC: etcd project proposal (incubation)

Chris Aniszczyk
 

Just a heads up, the etcd community published their incubation project proposal:

I'd like to invite the TOC and wider community to review it for a week or so before we call for a formal vote in the coming weeks.

Thanks!

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


Re: [VOTE] Prometheus moving to graduation

Jesse White
 

+1 (non-binding)


Re: [VOTE] Prometheus moving to graduation

Kai Chen
 

+1 (non-binding)

-Kai

From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
Date: Tuesday, April 17, 2018 at 7:56 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] Prometheus moving to graduation

Prometheus (https://prometheus.io) was the second project accepted in CNCF and has sustained an amazing growth of contributors and users since joining CNCF. We are moving forward with the graduation request from the Prometheus team after performing a review of the project: https://github.com/cncf/toc/pull/88

The Prometheus team believes it has fulfilled all the graduation criteria:

- A well defined governance model: https://prometheus.io/governance
- Used successfully in production by at least three independent end users of sufficient scale and quality: https://prometheus.io (see users end of page)
- Have a healthy number of committers: They have at least 17 committers from 10 different organizations: https://github.com/juliusv/toc/blob/6304e5807537402e5f7fd7a5b86864223cae5e0d/reviews/graduation-prometheus.md#have-committers-from-at-least-two-organizations
- Demonstrate a substantial ongoing flow of commits and merged contributions: They have had  850+ unique contributors with a total of 12k+ commits so far: https://prometheus.devstats.cncf.io

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

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: RSocket Followup (post TOC meeting)

Robert Roeser <robert@...>
 

 

Has it not actively sought contributors or users up to now? 

The project hasn’t sought active contributors until now.

 

What did the "language agnostic" point mean? 

RSocket is spec’d protocol (https://github.com/rsocket/rsocket/blob/master/Protocol.md), and not dependent on a language features for implementation. Right now, there are implementations in Java, Javascript, C++, and Kotlin. There is interest in Python and Golang implementation, and plans to implement these.

 

 

From: Brian Grant <briangrant@...>
Date: Tuesday, August 7, 2018 at 9:24 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: cncf-toc <cncf-toc@...>, Robert Roeser <robert@...>, "bhale@..." <bhale@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)

 

Thanks for the presentation.

 

It looks like the project has existed for about 3 years? Has it not actively sought contributors or users up to now? Development looks not very active and it has < 300 github stars.

 

 

What did the "language agnostic" point mean? Just that it has implementations in multiple languages (at least Java and C++ -- it's not clear which other languages are actively maintained/developed)?

 

On Tue, Aug 7, 2018 at 9:04 AM 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)

colin@...
 

Great presentation, RSocket is an interesting project - the flow control handling with the lease based model is impressive.  Speaking for myself and the NATS team, we’re happy to see more messaging related projects being proposed, giving CNCF end users more options to find the best fit for their use case.


In the past I’ve made product comparisons with incomplete information - it was a learning experience, and Alexis can vouch for that. :)  To that end, what does the TOC think of having public comparison cards for related projects, where project maintainers would provide their own input on their feature sets, implementation details, etc?  I think something along those lines would go a long way to help users educate themselves about different projects without bias, and this would facilitate the CNCF in providing guidance to end users.


In the slides, there are a few things I’d like to clarify.  But first, any suggestions on how we can improve our documentation to make our feature set and implementation details clearer would be much appreciated. My general clarification here is that while NATS uses a simple text based protocol, we are payload agnostic, supporting payloads of any type, including binary.


We do appreciate the product comparison. Here is some more detailed clarification.


Slide 36:

  • Binary - Is this referring to the protocol or payload support? ...NATS does supports binary payloads.
  • Max Payload Size - NATS can be configured to be effectively “unlimited”, although the default is 1MB.
  • Browser support:  To clarify, for NATS support is via third party but maintainer support is coming soon.
  • Bidirectional Channel:  Maybe N/A for NATS?. We support multiple streams (subjects) under a request/reply API, but at a lower level all of NATS is async.

Slide 37:

  • Inline Errors - N/A, we provide asynchronous error notifications.

Slide 38

  • NATS Languages - See https://nats.io/download/
  • Reactive Streams Support - Third Party
  • IPC - The protocol is text, but payloads are binary (payload agnostic).
  • Creators - We credit Derek Collison as the creator of NATS rather than a specific company or organization.

Again, we’re really happy to see more messaging projects proposed, and I hope this can clarify to create a more accurate project comparison.  I’d love to hear what people think about some sort of public feature set comparison, endorsed by the CNCF.

Thanks,
Colin

 


Re: RSocket Followup (post TOC meeting)

Brian Grant
 

Thanks for the presentation.

It looks like the project has existed for about 3 years? Has it not actively sought contributors or users up to now? Development looks not very active and it has < 300 github stars.


What did the "language agnostic" point mean? Just that it has implementations in multiple languages (at least Java and C++ -- it's not clear which other languages are actively maintained/developed)?

On Tue, Aug 7, 2018 at 9:04 AM 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
 

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


RSocket Followup (post TOC meeting)

Chris Aniszczyk
 


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: [VOTE] Prometheus moving to graduation

Brian Grant
 

+1 binding

On Fri, Aug 3, 2018 at 8:14 AM Bryan Cantrill <bryan@...> wrote:
+1 (binding)

        - Bryan


On Tue, Apr 17, 2018, 7:56 AM Chris Aniszczyk <caniszczyk@...> wrote:
Prometheus (https://prometheus.io) was the second project accepted in CNCF and has sustained an amazing growth of contributors and users since joining CNCF. We are moving forward with the graduation request from the Prometheus team after performing a review of the project: https://github.com/cncf/toc/pull/88

The Prometheus team believes it has fulfilled all the graduation criteria:

- A well defined governance model: https://prometheus.io/governance
- Used successfully in production by at least three independent end users of sufficient scale and quality: https://prometheus.io (see users end of page)
- Have a healthy number of committers: They have at least 17 committers from 10 different organizations: https://github.com/juliusv/toc/blob/6304e5807537402e5f7fd7a5b86864223cae5e0d/reviews/graduation-prometheus.md#have-committers-from-at-least-two-organizations
- Demonstrate a substantial ongoing flow of commits and merged contributions: They have had  850+ unique contributors with a total of 12k+ commits so far: https://prometheus.devstats.cncf.io

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

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] Prometheus moving to graduation

colin@...
 

+1 non-binding


TOC Agenda for 8/7/2018

Chris Aniszczyk
 

Hey all, we are meeting tomorrow:


We will be hearing a readout from the GB strategy meeting, prometheus graduation, along with community presentations from etcd and rsocket.

See everyone tomorrow!

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


Re: [VOTE] Prometheus moving to graduation

Mike Jacobi
 

+1 binding
-- NORMAL --


Re: [VOTE] Prometheus moving to graduation

eleven.xu@...
 

+1 non-binding

Thanks & Best Regards,

徐翔轩

----------------------------------------------------



上海得帆信息技术有限公司
  SHANGHAI DEFINESYS INFORMATION TECHNOLOGY CO., LTD.

E-mail : eleven.xu@...
Mobile : +86-186-1626-0537
Website:http://www.definesys.com

----------------------------------------------------
 

在 2018年8月6日,15:56,郑淮城 <huaicheng.zheng@...> 写道:

+1 non-binding
 
郑淮城
星环信息科技(上海)有限公司
15216615728
徐汇区虹漕路88号越虹广场B11-12
 
 
发件人: <cncf-toc@...> 代表 "Eichten, Daniel" <daniel.eichten@...>
日期: 201886 星期一 下午3:49
收件人: Pengfei Ni <feiskyer@...>, Chris Aniszczyk <caniszczyk@...>
抄送: CNCF TOC <cncf-toc@...>
主题: Re: [cncf-toc] [VOTE] Prometheus moving to graduation
 
+1 non-binding

Von: cncf-toc@... <cncf-toc@...> im Auftrag von Pengfei Ni <feiskyer@...>
Gesendet: Sonntag, 5. August 2018 14:39:50
An: Chris Aniszczyk
Cc: CNCF TOC
Betreff: Re: [cncf-toc] [VOTE] Prometheus moving to graduation
 
+1 (non-binding)

 


 
 
Best regards.
 
 
---
Pengfei Ni
 
 
2018-04-17 22:56 GMT+08:00 Chris Aniszczyk <caniszczyk@...>:
Prometheus (https://prometheus.io) was the second project accepted in CNCF and has sustained an amazing growth of contributors and users since joining CNCF. We are moving forward with the graduation request from the Prometheus team after performing a review of the project: https://github.com/cncf/toc/pull/88
 
The Prometheus team believes it has fulfilled all the graduation criteria:
 
- A well defined governance model: https://prometheus.io/governance
- Used successfully in production by at least three independent end users of sufficient scale and quality: https://prometheus.io (see users end of page)
- Have a healthy number of committers: They have at least 17 committers from 10 different organizations: https://github.com/juliusv/toc/blob/6304e5807537402e5f7fd7a5b86864223cae5e0d/reviews/graduation-prometheus.md#have-committers-from-at-least-two-organizations
- Demonstrate a substantial ongoing flow of commits and merged contributions: They have had  850+ unique contributors with a total of 12k+ commits so far: https://prometheus.devstats.cncf.io

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

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.


5561 - 5580 of 7763