|
Re: [VOTE] SAFE (Security) Working Group
Chase Pettet
+1 non-binding How awesome would it be to have common nomenclature and practices across similar methodology for CNCF projects. This in and of itself would be a huge value add CNCF can bring to the table. On Tue, Sep 4, 2018 at 8:50 AM, Chris Aniszczyk <caniszczyk@...> wrote:
--
Chase Pettet chasemp on phabricator and IRC |
|||
|
|
|||
|
Re: [VOTE] SAFE (Security) Working Group
Justin Cormack
+1 (non binding) On Tue, Sep 4, 2018 at 2:50 PM, Chris Aniszczyk <caniszczyk@...> wrote:
|
|||
|
|
|||
|
Re: [VOTE] SAFE (Security) Working Group
ytijani@...
+1 non-binding Le mar. 4 sept. 2018 à 15:52, Tom Phelan <tap@...> a écrit :
|
|||
|
|
|||
|
Re: [VOTE] SAFE (Security) Working Group
Tom Phelan
+1 (non-binding) On Tue, Sep 4, 2018 at 6:51 AM, Geri Jennings <geri.jennings@...> wrote:
--
|
|||
|
|
|||
|
Re: [VOTE] SAFE (Security) Working Group
Ken Owens
+1 binding On Tue, Sep 4, 2018 at 8:50 AM Chris Aniszczyk <caniszczyk@...> wrote:
|
|||
|
|
|||
|
Re: [VOTE] SAFE (Security) Working Group
+1 (non-binding)
From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
A new CNCF Working Group has been proposed (sponsored by Ken Owens):
Secure Access for Everyone (SAFE) Working Group will explore secure access, policy control and safety for operators, administrators, developers, and end-users across the cloud native ecosystem
Please vote (+1/0/-1) by replying to this thread; the full proposal located here: https://github.com/cncf/toc/pull/146
-- Chris Aniszczyk (@cra) | +1-512-961-6719 _______________________________________________ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. |
|||
|
|
|||
|
[VOTE] SAFE (Security) Working Group
A new CNCF Working Group has been proposed (sponsored by Ken Owens): Secure Access for Everyone (SAFE) Working Group will explore secure access, policy control and safety for operators, administrators, developers, and end-users across the cloud native ecosystem 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)
> why did you feel it necessary to add an additional layer of application flow control on top of what TCP already provides?
This is discussed in the FAQ of the project: https://github.com/rsocket/rsocket/blob/master/FAQ.md#why-reactive-streams-requestn-flow-control
The key difference is that RSocket offers end-to-end instead of hop-to-hop flow control and expects to have message-level flow control exposed through APIs into the application layer. This allows non-blocking bounded message queues in user code and prevents buffer bloating of intermediaries.
A key example is an experience I had with a load balancer (TCP, not HTTP in that case) where the hop-to-hop behavior did what it does best - filled the entire buffer of the proxy (load balancer) - which resulted in increasing latency of the end consumer (fast producer, slow consumer problem) until eventually the proxy would OOM and reboot. This required bad hacks to address since the protocol in use did not support end-to-end flow control. Neither HTTP or TCP expose end-to-end flow control mechanisms into the application layer, RSocket allows this.
The responses from Ben Hale earlier also did a good job of explaining this and provided further examples I won't repeat here. |
|||
|
|
|||
|
Re: RSocket Followup (post TOC meeting)
> Other than to support non-TCP transports (like UDP), which I would assume are fairly uncommon,
This is actually something we leverage in production:
- TCP for server-to-server
- WebSocket for browser-to-server
- single HTTP/2 stream treated like TCP on shared HTTP/2 connection
The need to target both WebSockets and TCP was actually a very concrete initial reason for creating RSocket, since HTTP/2 framing is not exposed in browsers or most client/server APIs. More on this is found in the Motivations doc: https://github.com/rsocket/rsocket/blob/master/FAQ.md#why-not-http2 |
|||
|
|
|||
|
Re: RSocket Followup (post TOC meeting)
> How much interoperability testing have you done?
We use rsocket-cpp, rsocket-js, and rsocket-java together. C++ as both client and server. JS as a client against C++ and Java, and recently starting to be a server (but that's less tested). Java as client against C++, and as server for JS.
We use TCP, WebSocket, and a single HTTP/2 stream on a shared connection in different places as the transport.
- For server-to-server we primarily use TCP.
- For browser-to-server we use WebSocket.
- For mobile-to-server we use a single H2 stream for RSocket on a potentially hared H2 connection.
- For mobile-to-server we are evaluating mapping RSocket streams onto HTTP/2 streams, while being multitenant with other protocols on the same HTTP/2 connection.
- Both approaches with HTTP/2 do not work with standard HTTP/2 APIs and only work because we expose internals of the protocol in our implementation. The mapping to H2 streams and being multi-tenant also requires custom extensions to H2 so isn't viable broadly (unless we evolve H2). And the H2 mapping does not work in browsers, so we use WebSockets there.
|
|||
|
|
|||
|
Re: TOC + Community Input: Cloud Native Buildpacks
Thanks Alexis, I let the folks know to put together an official proposal for the sandbox: On Tue, Aug 28, 2018 at 10:02 AM, Alexis Richardson <alexis@...> wrote: I am happy to co-sponsor. --
Chris Aniszczyk (@cra) | +1-512-961-6719 |
|||
|
|
|||
|
Re: TOC + Community Input: Cloud Native Buildpacks
alexis richardson
I am happy to co-sponsor.
alexis On Tue, Aug 21, 2018 at 4:45 PM, Chris Aniszczyk <caniszczyk@...> wrote: The buildpacks.io community presented at the TOC meeting today: |
|||
|
|
|||
|
Re: [VOTE] etcd project proposal (incubation)
Michael Hausenblas <mhausenb@...>
+1 (non-binding)
toggle quoted message
Show quoted text
Cheers, Michael -- Michael Hausenblas, Developer Advocate OpenShift by Red Hat Mobile: +353 86 0215164 | Twitter: @mhausenblas http://openshift.com | http://mhausenblas.info -----Original Message-----
From: Chris Aniszczyk <caniszczyk@...> Reply: Chris Aniszczyk <caniszczyk@...> Date: 21 August 2018 at 16:57:45 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, |
|||
|
|
|||
|
Re: Feedback on Cortex presentation + call for TOC sponsors
Tom Wilkie <tom.wilkie@...>
Thanks Bryan! On Wed, Aug 22, 2018 at 7:45 PM Chris Aniszczyk <caniszczyk@...> wrote:
|
|||
|
|
|||
|
Re: [VOTE] etcd project proposal (incubation)
Ken Owens
+1 Binding On Tue, Aug 21, 2018 at 6:34 PM Junghyun Kim <kjh@...> wrote:
|
|||
|
|
|||
|
Re: [VOTE] etcd project proposal (incubation)
Erin Boyd
+1 non-binding On Tue, Aug 21, 2018 at 9:35 AM, Isaac Mosquera via Lists.Cncf.Io <isaac=armory.io@...> wrote:
|
|||
|
|
|||
|
Re: [VOTE] etcd project proposal (incubation)
Tamal Saha
+1 non-binding Regards, -Tamal On Tue, Aug 21, 2018 at 7:57 AM Chris Aniszczyk <caniszczyk@...> wrote:
|
|||
|
|
|||
|
Re: [VOTE] etcd project proposal (incubation)
iftach Schonbaum
+1 non-binding
From: <cncf-toc@...> on behalf of 郑淮城 <huaicheng.zheng@...>
+1 non-binding
郑淮城
发件人:
<cncf-toc@...>
代表 Chris Aniszczyk <caniszczyk@...>
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
-- Chris Aniszczyk (@cra) | +1-512-961-6719 |
|||
|
|
|||
|
Re: [VOTE] etcd project proposal (incubation)
郑淮城 <huaicheng.zheng@...>
+1 non-binding
郑淮城
发件人: <cncf-toc@...> 代表 Chris Aniszczyk <caniszczyk@...>
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
-- Chris Aniszczyk (@cra) | +1-512-961-6719 |
|||
|
|
|||
|
Re: [VOTE] etcd project proposal (incubation)
colin@...
+1 non-binding
|
|||
|
|
