1) Do RDS other than rate limit. This is large enough will do that next.
2) Manually order top level in v2 with better titles
3) Random other fixes
Note also that I'm going to manually reorder the protos in some cases in a
follow up so the docs make a bit more sense for a casual reader.
Signed-off-by: Matt Klein <mklein@lyft.com>
* [#not-implemented-hide:] will hide a message/enum/field from docs.
* [#not-implemented-warn:] will add a "Not implemented yet" warning to a
message/enum/field.
* [#v2-api-diff:<text>] will add a note indicating v2 API difference to
a message/enum/field.
* Switched title annotation to [#protodoc-title:<text>] for consistency.
Signed-off-by: Harvey Tuch <htuch@google.com>
Instead of having TOC elements like api/base.proto, we could add a title to protos with prefix
protodoc-title: <title>. These will be converted into page titles and stripped from the docs before rendering.
Signed-off-by: Shriram Rajagopalan <shriram@us.ibm.com>
Turns out that files with just service methods don't get loaded into the
descriptor pool automatically in C++. So, needed to have some messages
in ads.proto. Turns out this was a good opportunity to move some of the
messages that were related to discovery out of base.proto.
This shouldn't break the API, since everything is in the envoy.api.v2
packge space.
Needed for empty resource responses to allow the xDS API the response is
pointing at to be identified. In non-empty resource responses, the
type_url is embedded in the Any messages.
Since we may want to use a resolver plugin in most places, it doesn't
make sense to have this strong separation between the two in the API.
Also bonus renumbering cleanup in LDS.
Since we expeceted both node name and cluster in v1, it makes sense to
continue providing this to management servers. We don't need to use
metadata for cluster if it is required.
Add metadata to endpoints in EDS.
Allow routes to specify a metadata_match. WeightedClusters can further
specify an additional metadata_match based on weighting.
Log all metadata. It makes sense to have available to the logging
pipeline all metadata used during request processing, not just some
that is explicitly annotated. This then makes available the endpoint's
metadata for log consumption. The tradeoff is that this will increase
log sizes when metadata is plentiful. We may want to consider a way to
filter this in logs in the future.
Fixes#81 and #91.
This patch adds a static bootstrap proto that is expected to be provided
on the filesystem or command-line. This should enable Envoy to then
either fetch the rest of config from disk or reach out to the various
management servers for the rest of the APIs.
Fixes#93.
* Factor all subscription responses to DiscoveryResponse message with an Any
resource type. This further simplifies the Subscription interface in
the Envoy client, as it no longer needs to be templatized on the
response type.
* Replace version_info bytes type with string. This allows plain
strings to be used in JSON representations rather than base64 encoded
strings as required in the canonical proto3 translation of bytes.
* Clarify ACK/NACK semantics with version_info in comments.
Fixes#85.
This PR allows for easier implementation of a unified subscription model
in Envoy for gRPC/REST/inotify filesystem config updates:
* The DiscoveryRequest basically looks the same in all subscription APIs
today, so factored out to DiscoveryRequest.
* xDiscoveryResponse now uses a consistent convention. This will allow
C++ template level duck typing to populate the response in a single
implementation for all APIs. This is mostly relevant for the filesystem
watch implementation, where we need to map from resource names to file
paths, but could also make API server implementation easier
potentially.
While still supporting only 2 priorities today, this PR leaves room for
an additional finite number of priorities via enum extension. Since
we're not planning on reflecting arbitrary downstream priorities in the
upstream connection, we only expect a small number of priorities to be
useful in configuring routes and clusters.
Fixes#1.
There are multiple uses for opaque metadata that is associated with the
specific listener/filter chain/route that a request matches on:
1. Logging. Similar to header values, we can log the metadata values.
A listener might belong to a higher level concept in the
configuration language that generated LDS protos, e.g. there might be
a rule identifier expressed. This metadata allows logs to reflect the
rule identifier.
2. Future custom stats backends might use metadata to guide where and
how stats are emitted. E.g. the metadata might include information
about which stats collector to emit to.
3. Proprietary filters can receive additional inputs via the metadata.
The per-filter metadata generalizes and replaces the opaque_config in
RDS ForwardAction.
The metadata is structured such that each filter's metadata is under the
reverse DNS namespace defined by the filter. Shared metadata may be
arranged by coordinating on the reverse DNS namespace.
As an example, the "envoy.http_connection_manager.access_log" filter
namespace is suggested to be used for HTTP access logging.
Fixes#33.
Matt Klein
htuch
Stephan Zuercher
Lizan Zhou
Shriram Rajagopalan
Kuat
Matt Klein
Harvey Tuch