cncf / udpa

🌌📊✈Universal Data Plane API Working Group (UDPA-WG)

This repository exists for archival purposes only, please see https://github.com/cncf/xds for active development of the xDS APIs.

udpa's Issues

Install repokitteh for wait commands

Support for Go 1.11 with GO111MODULES=on

It seems that #8 introduced a hard dependency on Go 1.13. 1.12 is still supported by the Go language team. And while 1.11 is no longer supported, it is still critical for environments like appengine, which have not yet dropped support. I ran into this problem while trying to compile grpcurl with Go 1.11 (PR):

go test -race ./...
go build golang.org/x/sys/unix: module requires Go 1.12
go build github.com/cncf/udpa/go/udpa/annotations: module requires Go 1.13
go build github.com/envoyproxy/go-control-plane/envoy/annotations: module requires Go 1.12
go build github.com/envoyproxy/go-control-plane/envoy/type: module requires Go 1.12
FAIL	github.com/fullstorydev/grpcurl [build failed]
FAIL	github.com/fullstorydev/grpcurl/cmd/grpcurl [build failed]
Makefile:82: recipe for target 'test' failed

There seems to be a general problem with the Go tooling auto-inserting hard dependencies like this when none was intended by the author. Is that the case here? Or is there some feature that the library truly does depend on in Go 1.13+?

CC @kyessenov
CC @htuch

Update protoc version

It would be great to have the generated protos use the same versions as Envoy. In particular, I am interested in them using the newer golang version (https://blog.golang.org/protobuf-apiv2).

The current protos implement github.com/golang/protobuf.Message but not google.golang.org/protobuf.Message which limits its usage.

I tried updating myself but bazel is 🤯

Question: Could we have a v1?

gRPC-Go has a dependency on the pb.gos published from here. #40 changed the path of these pb.gos. Currently gRPC-Go's depends on a specific commit.

It would be bad for us to depend on a v0 for any non-experimental features that we support. Is there a plan to publish a v1 anytime soon?

Thank you.

About the definition of general rate-limit rule API.

I am investigating UDPA of the rate-limit related rules recently, and found a related discussion here, I hope it could be discussed in UDPA WG. @lizan @htuch @mattklein123
thx

Please make a release

Go expects a released version for go mod to produce reliable builds. It would be sufficient to make a tag with a name v0.0.1.

Question: UDPA implemented using eBPF

As eBPF enjoys increasing uptake, I was wondering if anyone has been looking into implementing UDPA using eBPF? I came across the Dropbox engineering report on their migration story to Envoy and hence would be interested to learn what others see or think about this.

Context parameters in UDPA URIs embedded in server returned resources

The treatments of context parameters in xDS transport next steps indicates that client context parameters, e.g. node metadata, are unconditionally included in URIs placed in discovery requests.

This makes sense for URIs that originate at the client, e.g. those found in a bootstrap file, but not so much for URIs provided in server returned resources, e.g. a RDS URI in an LDS response. In the server returned URI case, we should not force the client to have to include potentially irrelevant metadata. There are multiple rationales for this:

• This reduces the amount of noise in and size of URIs when the node metadata is irrelevant.
• Caching can be improved by not having to consider node metadata for resources where it's immaterial.
• This matches a RESTful style of resource management, which provides a well-understood division of responsibility.
• The server can always add the context parameters to URIs in returned resources based on the resources' URI context parameters if needed.

The only potential downside is that the server may need to do some additional work in generating embedded URIs when it is necessary to propagate node metadata context parameters to resource dependencies.

I'd like to propose an addendum to xDS transport next steps where we limit per-node client capabilities (and possibly client feature capabilities) to URIs that originate on the client.

@markdroth @louiscryan @howardjohn @costinm @mattklein123 @envoyproxy/udpa-wg

RFC process for UDPA

We've recently adopted xDS transport next steps as plan-of-record for xDS transport evolution. This is effectively the UDPA transport protocol. I've just opened #32 to propose an addendum to clarify some behavior around context parameters.

I think at this point, rather than working with Google Docs and GitHub issues, it makes sense to switch to a process where we track changes in lightweight GitHub RFC docs. An example that I think will serve well is the gRPC RFC process, aka gRFC. This has the advantage of provided a reference, a fairly lightweight review process, not too much boilerplate and allows us to focus discussions via PR review.

If this sounds reasonable, I can draft up a PR with a template and process for uRFCs (UDPA RFCs).

@markdroth @louiscryan @howardjohn @costinm @mattklein123 @envoyproxy/udpa-wg