Until the SNI feature arrives, we need this in order to have a usable V2 API plane. I have retained the configuration format as is (comma separated port list, etc.) so as to get a working implementation first.
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.
Direction is implied at the C++ type level, putting this in the config
is redundant and can making changes to the C++ implementations difficult
to synchronize between binary and config.
Fixes#63.
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.
When doing logging to RPC endpoints in proto format we need to know two
config details:
The RPC endpoint. This is a string like the path, but rather than
semantic overloading make this explicit.
Custom headers to include. We'll populate all of the names fields in
the AccessLog proto but users can also specify custom request and
response headers they want to log.
TCP proxy filter now has an idle timeout and the source match (and rest
of route match as well) are now in the FilterChainMatch in
https://github.com/lyft/envoy-api/pull/49.
Fixes#23, #45.
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
Shriram Rajagopalan
Greg Greenway
Stephan Zuercher
Kuat
Piotr Sikora
htuch
Matt Rice
Dan Noé