Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support gRPC streams in addition to HTTP #813

Closed
markfisher opened this issue May 4, 2018 · 6 comments
Closed

support gRPC streams in addition to HTTP #813

markfisher opened this issue May 4, 2018 · 6 comments
Assignees
Labels
area/networking kind/feature Well-understood/specified features, ready for coding.
Milestone

Comments

@markfisher
Copy link

/area API
/kind dev

If Elafros defines a gRPC service that passes messages via bidirectional streams, any binding for that gRPC service could be used several ways:

  1. directly within applications that add a binding as a dependency
  2. indirectly via a bridge (e.g. HTTP -> gRPC) provided as a sidecar/ambassador container
  3. in function invokers, so that user code is simply called with an idiomatic stream type for its language

For example:

syntax = "proto3";

package function;

message Message {
	bytes payload = 1;
	map<string, string> headers = N;
}

service MessageFunction {
  rpc Call(stream Message) returns (stream Message) {}
}

Since gRPC traffic can be handled by Istio/Envoy, the management of traffic, policies, etc. should be consistent.

The goal of this issue is to establish the need for the foundational primitive that enables building higher level streaming constructs. From a platform implementer’s perspective, the domain of stream processing can lead to many challenges. It may not necessarily be within the realm of Elafros to address those challenges directly, but Elafros should provide the building blocks that enable streaming systems to be built in a way that aligns with the paradigm shift in developer experience being driven by serverless functions.

@google-prow-robot google-prow-robot added area/API API objects and controllers kind/feature Well-understood/specified features, ready for coding. labels May 4, 2018
@bsnchan
Copy link
Contributor

bsnchan commented May 14, 2018

/assign @bsnchan @dprotaso

@bsnchan
Copy link
Contributor

bsnchan commented Jul 4, 2018

It looks like the PR to update to the latest Istio version (#1228) does not support gRPC out of the box.

All the requests are sent using HTTP1 instead of the expected h2c.

@bsnchan
Copy link
Contributor

bsnchan commented Jul 5, 2018

It looks like in order to support GRPC, we'll need the following:

  • The knative-ingressgateway will need to have an exposed port with HTTP2 or GRPC as the protocol. (spec here)
  • The revision service's ports must also be named with the protocol (spec here)

@evankanderson
Copy link
Member

FWIW, golang/go#25363 has been closed, which means that h2c support has landed in golang.org/x/net/http2/h2c.

@dprotaso
Copy link
Member

dprotaso commented Jul 30, 2018 via email

dturanski referenced this issue in matthewmcnew/python3-function-invoker Oct 9, 2018
@mattmoor
Copy link
Member

/area networking

Is this a duplicate of: #707 If not, how is it different?

/remove-area API

I'm removing the API area for now because the control-plane implications are not clear. If we need control plane changes, then please detail them and add back the label (maybe in a dedicated issue, since this feels like a meta-tracking-issue for an epic).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking kind/feature Well-understood/specified features, ready for coding.
Projects
None yet
Development

No branches or pull requests

8 participants