v2 api changes: Use oneof to specify header match options, based on value(exact_match), regex or range.
The existing value and regex fields will be deprecated. Use the header_match_specfier oneof instead.
Add a new range.proto (envoy.type.v2) for the range type definition.
The SInt64Range message is defined in envoy.type.v2 range.proto.
It consists of start and end (inclusive, exclusive) sint64 values.
v1 api: Add a range_match object to the route headers json. Presence of this object indicates range based route match.
Example: For the below route config:
{
"prefix": "/",
"cluster": "PartitionB",
"name": "PartitionKey",
"range_match": { "start": 0, "end": 10}
}
In the incoming request, if the PartitionKey header value = 0, route match succeeds. Route match fails if the header value = 10, -10, "somestring".
This feature can be used for request routing with Service Fabric stateful services, to route to the desired partition with the [ranged partitioning scheme](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-concepts-partitioning#ranged-partitioning-scheme)
Signed-off-by: Kavya Kotacherry <kavyako@microsoft.com>
There are several main changes in this PR:
Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos.
Create individual packages for each filter and add independent versioning to each filter.
Add visibility constraints to prevent formation of dependency cycles.
Add gogoproto annotations to improve go code generation.
After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package.
The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane).
Added a few gogoproto annotations to improve golang code generation.
Signed-off-by: Kuat Yessenov <kuat@google.com>
* protodoc: make protodoc fast again.
Some low hanging fruit optimizations. This takes address.proto.rst build
from ~21s to ~1.7s.
Signed-off-by: Harvey Tuch <htuch@google.com>
In support of https://github.com/envoyproxy/envoy/issues/2200 and some
Google internal needs, we are planning on adding support to Envoy to
allow a configuration (or possibly build) driven decision on whether to
using the existing Envoy in-built Grpc::AsyncClient or
the Google C++ gRPC client library (https://grpc.io/grpc/cpp/index.html).
To move in this direction, the idea is we have the xDS ApiConfigSources,
rate limit service config and other filter configurations point at a
GrpcService object. This can be configured to use an Envoy cluster,
where Grpc::AsyncClient will orchestrate communication, or to contain
the config needed to establish a channel in Google C++ gRPC client
library.
Signed-off-by: Harvey Tuch <htuch@google.com>
As a source of entire Envoy version number. Will use this file in envoy
main repo as well.
By this change, document version string will be changed in development
version:
from: "1.6.0-data-plane-api-${GIT_SHA}"
to: "1.6.0.dev-data-plane-api-${GIT_SHA}"
And in release version, for example, in v1.6.0 release:
from: "1.6.0-tag-v1.6.0"
to: "tag-v1.6.0"
The significant change is dropping the first version number string like
"1.6.0-" in the release version document.
Signed-off-by: Taiki Ono <taiks.4559@gmail.com>
This patch adds an overview page introduced the v2 API concepts via a
worked example. Brought in the entire transitive dep set of protos from
bootstrap.proto, none of these have been cleaned up beyond the minimum
required to have them build under Sphinx.
Also added the ability to link to the underlying proto in messages/enums
from protodoc.py generated RST.
Signed-off-by: Harvey Tuch <htuch@google.com>
This PR just fixes enough stuff to get the HTTP connection manager filter
docs building. I want to get this out as it conflicts with other inflight
PRs and some of the work can be split up. E.g., access logging with that
in flight PR.
Signed-off-by: Matt Klein <mklein@lyft.com>
This should provide an example of how to do the .proto doc linking,
refactoring and constraint addition for the full API.
Signed-off-by: Harvey Tuch <htuch@google.com>
1) Allow release string to be specified by env var
2) Add pre-release warning text
This will be overriden during the official tagged doc builds in the main repo.
Signed-off-by: Matt Klein <mklein@lyft.com>
This takes us to the point where address.proto format in a style fairly
similar to the existing docs. There's some missing bits, e.g. oneof/enum
support, nested messages, optional/required, these will come as later
PRs.
Signed-off-by: Harvey Tuch <htuch@google.com>
Kavya Kotacherry - MSFT
Kuat
Gabriel Sagula
htuch
ramaraochavali
Taiki Ono
Yuval Kohavi
Matt Klein