|
|
|
syntax = "proto3";
|
|
|
|
|
|
|
|
package envoy.api.v2.core;
|
|
|
|
|
|
|
|
import "envoy/api/v2/core/http_uri.proto";
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
import "envoy/type/percent.proto";
|
|
|
|
import "envoy/type/semantic_version.proto";
|
|
|
|
|
|
|
|
import "google/protobuf/any.proto";
|
|
|
|
import "google/protobuf/struct.proto";
|
|
|
|
import "google/protobuf/wrappers.proto";
|
|
|
|
|
|
|
|
import "udpa/annotations/migrate.proto";
|
|
|
|
import "validate/validate.proto";
|
|
|
|
|
|
|
|
option java_package = "io.envoyproxy.envoy.api.v2.core";
|
|
|
|
option java_outer_classname = "BaseProto";
|
|
|
|
option java_multiple_files = true;
|
|
|
|
option (udpa.annotations.file_migrate).move_to_package = "envoy.config.core.v3alpha";
|
|
|
|
|
|
|
|
// [#protodoc-title: Common types]
|
|
|
|
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
// Envoy supports :ref:`upstream priority routing
|
|
|
|
// <arch_overview_http_routing_priority>` both at the route and the virtual
|
|
|
|
// cluster level. The current priority implementation uses different connection
|
|
|
|
// pool and circuit breaking settings for each priority level. This means that
|
|
|
|
// even for HTTP/2 requests, two physical connections will be used to an
|
|
|
|
// upstream host. In the future Envoy will likely support true HTTP/2 priority
|
|
|
|
// over a single upstream connection.
|
|
|
|
enum RoutingPriority {
|
|
|
|
DEFAULT = 0;
|
|
|
|
HIGH = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// HTTP request method.
|
|
|
|
enum RequestMethod {
|
|
|
|
METHOD_UNSPECIFIED = 0;
|
|
|
|
GET = 1;
|
|
|
|
HEAD = 2;
|
|
|
|
POST = 3;
|
|
|
|
PUT = 4;
|
|
|
|
DELETE = 5;
|
|
|
|
CONNECT = 6;
|
|
|
|
OPTIONS = 7;
|
|
|
|
TRACE = 8;
|
|
|
|
PATCH = 9;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Identifies the direction of the traffic relative to the local Envoy.
|
|
|
|
enum TrafficDirection {
|
|
|
|
// Default option is unspecified.
|
|
|
|
UNSPECIFIED = 0;
|
|
|
|
|
|
|
|
// The transport is used for incoming traffic.
|
|
|
|
INBOUND = 1;
|
|
|
|
|
|
|
|
// The transport is used for outgoing traffic.
|
|
|
|
OUTBOUND = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Identifies location of where either Envoy runs or where upstream hosts run.
|
|
|
|
message Locality {
|
|
|
|
// Region this :ref:`zone <envoy_api_field_core.Locality.zone>` belongs to.
|
|
|
|
string region = 1;
|
|
|
|
|
|
|
|
// Defines the local service zone where Envoy is running. Though optional, it
|
|
|
|
// should be set if discovery service routing is used and the discovery
|
|
|
|
// service exposes :ref:`zone data <envoy_api_field_endpoint.LocalityLbEndpoints.locality>`,
|
|
|
|
// either in this message or via :option:`--service-zone`. The meaning of zone
|
|
|
|
// is context dependent, e.g. `Availability Zone (AZ)
|
|
|
|
// <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html>`_
|
|
|
|
// on AWS, `Zone <https://cloud.google.com/compute/docs/regions-zones/>`_ on
|
|
|
|
// GCP, etc.
|
|
|
|
string zone = 2;
|
|
|
|
|
|
|
|
// When used for locality of upstream hosts, this field further splits zone
|
|
|
|
// into smaller chunks of sub-zones so they can be load balanced
|
|
|
|
// independently.
|
|
|
|
string sub_zone = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
// BuildVersion combines SemVer version of extension with free-form build information
|
|
|
|
// (i.e. 'alpha', 'private-build') as a set of strings.
|
|
|
|
message BuildVersion {
|
|
|
|
// SemVer version of extension.
|
|
|
|
type.SemanticVersion version = 1;
|
|
|
|
|
|
|
|
// Free-form build information.
|
|
|
|
// Envoy defines several well known keys in the source/common/common/version.h file
|
|
|
|
google.protobuf.Struct metadata = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Version and identification for an Envoy extension.
|
|
|
|
// [#next-free-field: 6]
|
|
|
|
message Extension {
|
|
|
|
// This is the name of the Envoy filter as specified in the Envoy
|
|
|
|
// configuration, e.g. envoy.router, com.acme.widget.
|
|
|
|
string name = 1;
|
|
|
|
|
|
|
|
// Category of the extension.
|
|
|
|
// Extension category names use reverse DNS notation. For instance "envoy.filters.listener"
|
|
|
|
// for Envoy's built-in listener filters or "com.acme.filters.http" for HTTP filters from
|
|
|
|
// acme.com vendor.
|
|
|
|
// [#comment:TODO(yanavlasov): Link to the doc with existing envoy category names.]
|
|
|
|
string category = 2;
|
|
|
|
|
|
|
|
// [#not-implemented-hide:] Type descriptor of extension configuration proto.
|
|
|
|
// [#comment:TODO(yanavlasov): Link to the doc with existing configuration protos.]
|
|
|
|
// [#comment:TODO(yanavlasov): Add tests when PR #9391 lands.]
|
|
|
|
string type_descriptor = 3;
|
|
|
|
|
|
|
|
// The version is a property of the extension and maintained independently
|
|
|
|
// of other extensions and the Envoy API.
|
|
|
|
// This field is not set when extension did not provide version information.
|
|
|
|
BuildVersion version = 4;
|
|
|
|
|
|
|
|
// Indicates that the extension is present but was disabled via dynamic configuration.
|
|
|
|
bool disabled = 5;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Identifies a specific Envoy instance. The node identifier is presented to the
|
|
|
|
// management server, which may use this identifier to distinguish per Envoy
|
|
|
|
// configuration for serving.
|
|
|
|
// [#next-free-field: 11]
|
|
|
|
message Node {
|
|
|
|
// An opaque node identifier for the Envoy node. This also provides the local
|
|
|
|
// service node name. It should be set if any of the following features are
|
|
|
|
// used: :ref:`statsd <arch_overview_statistics>`, :ref:`CDS
|
|
|
|
// <config_cluster_manager_cds>`, and :ref:`HTTP tracing
|
|
|
|
// <arch_overview_tracing>`, either in this message or via
|
|
|
|
// :option:`--service-node`.
|
|
|
|
string id = 1;
|
|
|
|
|
|
|
|
// Defines the local service cluster name where Envoy is running. Though
|
|
|
|
// optional, it should be set if any of the following features are used:
|
|
|
|
// :ref:`statsd <arch_overview_statistics>`, :ref:`health check cluster
|
|
|
|
// verification <envoy_api_field_core.HealthCheck.HttpHealthCheck.service_name>`,
|
|
|
|
// :ref:`runtime override directory <envoy_api_msg_config.bootstrap.v2.Runtime>`,
|
|
|
|
// :ref:`user agent addition
|
|
|
|
// <envoy_api_field_config.filter.network.http_connection_manager.v2.HttpConnectionManager.add_user_agent>`,
|
|
|
|
// :ref:`HTTP global rate limiting <config_http_filters_rate_limit>`,
|
|
|
|
// :ref:`CDS <config_cluster_manager_cds>`, and :ref:`HTTP tracing
|
|
|
|
// <arch_overview_tracing>`, either in this message or via
|
|
|
|
// :option:`--service-cluster`.
|
|
|
|
string cluster = 2;
|
|
|
|
|
|
|
|
// Opaque metadata extending the node identifier. Envoy will pass this
|
|
|
|
// directly to the management server.
|
|
|
|
google.protobuf.Struct metadata = 3;
|
|
|
|
|
|
|
|
// Locality specifying where the Envoy instance is running.
|
|
|
|
Locality locality = 4;
|
|
|
|
|
|
|
|
// This is motivated by informing a management server during canary which
|
|
|
|
// version of Envoy is being tested in a heterogeneous fleet. This will be set
|
|
|
|
// by Envoy in management server RPCs.
|
|
|
|
// This field will be deprecated in favor of the user_agent_name and user_agent_version values.
|
|
|
|
// [#comment:TODO(yanavlasov): Deprecate once issue #9604 is fixed.]
|
|
|
|
string build_version = 5;
|
|
|
|
|
|
|
|
// Free-form string that identifies the entity requesting config.
|
|
|
|
// E.g. "envoy" or "grpc"
|
|
|
|
string user_agent_name = 6;
|
|
|
|
|
|
|
|
oneof user_agent_version_type {
|
|
|
|
// Free-form string that identifies the version of the entity requesting config.
|
|
|
|
// E.g. "1.12.2" or "abcd1234", or "SpecialEnvoyBuild"
|
|
|
|
string user_agent_version = 7;
|
|
|
|
|
|
|
|
// Structured version of the entity requesting config.
|
|
|
|
BuildVersion user_agent_build_version = 8;
|
|
|
|
}
|
|
|
|
|
|
|
|
// List of extensions and their versions supported by the node.
|
|
|
|
repeated Extension extensions = 9;
|
|
|
|
|
|
|
|
// Client feature support list. These are well known features described
|
|
|
|
// in the Envoy API repository for a given major version of an API. Client features
|
|
|
|
// use reverse DNS naming scheme, for example `com.acme.feature`.
|
|
|
|
// See :ref:`the list of features <client_features>` that xDS client may
|
|
|
|
// support.
|
|
|
|
repeated string client_features = 10;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Metadata provides additional inputs to filters based on matched listeners,
|
|
|
|
// filter chains, routes and endpoints. It is structured as a map, usually from
|
|
|
|
// filter name (in reverse DNS format) to metadata specific to the filter. Metadata
|
|
|
|
// key-values for a filter are merged as connection and request handling occurs,
|
|
|
|
// with later values for the same key overriding earlier values.
|
|
|
|
//
|
|
|
|
// An example use of metadata is providing additional values to
|
|
|
|
// http_connection_manager in the envoy.http_connection_manager.access_log
|
|
|
|
// namespace.
|
|
|
|
//
|
|
|
|
// Another example use of metadata is to per service config info in cluster metadata, which may get
|
|
|
|
// consumed by multiple filters.
|
|
|
|
//
|
|
|
|
// For load balancing, Metadata provides a means to subset cluster endpoints.
|
|
|
|
// Endpoints have a Metadata object associated and routes contain a Metadata
|
|
|
|
// object to match against. There are some well defined metadata used today for
|
|
|
|
// this purpose:
|
|
|
|
//
|
|
|
|
// * ``{"envoy.lb": {"canary": <bool> }}`` This indicates the canary status of an
|
|
|
|
// endpoint and is also used during header processing
|
|
|
|
// (x-envoy-upstream-canary) and for stats purposes.
|
|
|
|
// [#next-major-version: move to type/metadata/v2]
|
|
|
|
message Metadata {
|
|
|
|
// Key is the reverse DNS filter name, e.g. com.acme.widget. The envoy.*
|
|
|
|
// namespace is reserved for Envoy's built-in filters.
|
|
|
|
map<string, google.protobuf.Struct> filter_metadata = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Runtime derived uint32 with a default when not specified.
|
|
|
|
message RuntimeUInt32 {
|
|
|
|
// Default value if runtime value is not available.
|
|
|
|
uint32 default_value = 2;
|
|
|
|
|
|
|
|
// Runtime key to get value for comparison. This value is used if defined.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
string runtime_key = 3 [(validate.rules).string = {min_bytes: 1}];
|
|
|
|
}
|
|
|
|
|
|
|
|
// Runtime derived bool with a default when not specified.
|
|
|
|
message RuntimeFeatureFlag {
|
|
|
|
// Default value if runtime value is not available.
|
|
|
|
google.protobuf.BoolValue default_value = 1 [(validate.rules).message = {required: true}];
|
|
|
|
|
|
|
|
// Runtime key to get value for comparison. This value is used if defined. The boolean value must
|
|
|
|
// be represented via its
|
|
|
|
// `canonical JSON encoding <https://developers.google.com/protocol-buffers/docs/proto3#json>`_.
|
|
|
|
string runtime_key = 2 [(validate.rules).string = {min_bytes: 1}];
|
|
|
|
}
|
|
|
|
|
|
|
|
// Header name/value pair.
|
|
|
|
message HeaderValue {
|
|
|
|
// Header name.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
string key = 1 [(validate.rules).string = {min_bytes: 1 max_bytes: 16384}];
|
|
|
|
|
|
|
|
// Header value.
|
|
|
|
//
|
|
|
|
// The same :ref:`format specifier <config_access_log_format>` as used for
|
|
|
|
// :ref:`HTTP access logging <config_access_log>` applies here, however
|
|
|
|
// unknown header values are replaced with the empty string instead of `-`.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
string value = 2 [(validate.rules).string = {max_bytes: 16384}];
|
|
|
|
}
|
|
|
|
|
|
|
|
// Header name/value pair plus option to control append behavior.
|
|
|
|
message HeaderValueOption {
|
|
|
|
// Header name/value pair that this option applies to.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
HeaderValue header = 1 [(validate.rules).message = {required: true}];
|
|
|
|
|
|
|
|
// Should the value be appended? If true (default), the value is appended to
|
|
|
|
// existing values.
|
|
|
|
google.protobuf.BoolValue append = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Wrapper for a set of headers.
|
|
|
|
message HeaderMap {
|
|
|
|
repeated HeaderValue headers = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Data source consisting of either a file or an inline value.
|
|
|
|
message DataSource {
|
|
|
|
oneof specifier {
|
|
|
|
option (validate.required) = true;
|
|
|
|
|
|
|
|
// Local filesystem data source.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
string filename = 1 [(validate.rules).string = {min_bytes: 1}];
|
|
|
|
|
|
|
|
// Bytes inlined in the configuration.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
bytes inline_bytes = 2 [(validate.rules).bytes = {min_len: 1}];
|
|
|
|
|
|
|
|
// String inlined in the configuration.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
string inline_string = 3 [(validate.rules).string = {min_bytes: 1}];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// The message specifies how to fetch data from remote and how to verify it.
|
|
|
|
message RemoteDataSource {
|
|
|
|
// The HTTP URI to fetch the remote data.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
HttpUri http_uri = 1 [(validate.rules).message = {required: true}];
|
|
|
|
|
|
|
|
// SHA256 string for verifying data.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
string sha256 = 2 [(validate.rules).string = {min_bytes: 1}];
|
|
|
|
}
|
|
|
|
|
|
|
|
// Async data source which support async data fetch.
|
|
|
|
message AsyncDataSource {
|
|
|
|
oneof specifier {
|
|
|
|
option (validate.required) = true;
|
|
|
|
|
|
|
|
// Local async data source.
|
|
|
|
DataSource local = 1;
|
|
|
|
|
|
|
|
// Remote async data source.
|
|
|
|
RemoteDataSource remote = 2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Configuration for transport socket in :ref:`listeners <config_listeners>` and
|
|
|
|
// :ref:`clusters <envoy_api_msg_Cluster>`. If the configuration is
|
|
|
|
// empty, a default transport socket implementation and configuration will be
|
|
|
|
// chosen based on the platform and existence of tls_context.
|
|
|
|
message TransportSocket {
|
|
|
|
// The name of the transport socket to instantiate. The name must match a supported transport
|
|
|
|
// socket implementation.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
string name = 1 [(validate.rules).string = {min_bytes: 1}];
|
|
|
|
|
|
|
|
// Implementation specific configuration which depends on the implementation being instantiated.
|
|
|
|
// See the supported transport socket implementations for further documentation.
|
|
|
|
oneof config_type {
|
|
|
|
google.protobuf.Struct config = 2 [deprecated = true];
|
|
|
|
|
|
|
|
google.protobuf.Any typed_config = 3;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Generic socket option message. This would be used to set socket options that
|
|
|
|
// might not exist in upstream kernels or precompiled Envoy binaries.
|
|
|
|
// [#next-free-field: 7]
|
|
|
|
message SocketOption {
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
enum SocketState {
|
|
|
|
// Socket options are applied after socket creation but before binding the socket to a port
|
|
|
|
STATE_PREBIND = 0;
|
|
|
|
|
|
|
|
// Socket options are applied after binding the socket to a port but before calling listen()
|
|
|
|
STATE_BOUND = 1;
|
|
|
|
|
|
|
|
// Socket options are applied after calling listen()
|
|
|
|
STATE_LISTENING = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// An optional name to give this socket option for debugging, etc.
|
|
|
|
// Uniqueness is not required and no special meaning is assumed.
|
|
|
|
string description = 1;
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
|
|
|
|
// Corresponding to the level value passed to setsockopt, such as IPPROTO_TCP
|
|
|
|
int64 level = 2;
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
|
|
|
|
// The numeric name as passed to setsockopt
|
|
|
|
int64 name = 3;
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
|
|
|
|
oneof value {
|
|
|
|
option (validate.required) = true;
|
|
|
|
|
|
|
|
// Because many sockopts take an int value.
|
|
|
|
int64 int_value = 4;
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
|
|
|
|
// Otherwise it's a byte buffer.
|
|
|
|
bytes buf_value = 5;
|
|
|
|
}
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
|
|
|
|
// The state in which the option will be applied. When used in BindConfig
|
|
|
|
// STATE_PREBIND is currently the only valid value.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
SocketState state = 6 [(validate.rules).enum = {defined_only: true}];
|
|
|
|
}
|
|
|
|
|
|
|
|
// Runtime derived FractionalPercent with defaults for when the numerator or denominator is not
|
|
|
|
// specified via a runtime key.
|
|
|
|
//
|
|
|
|
// .. note::
|
|
|
|
//
|
|
|
|
// Parsing of the runtime key's data is implemented such that it may be represented as a
|
|
|
|
// :ref:`FractionalPercent <envoy_api_msg_type.FractionalPercent>` proto represented as JSON/YAML
|
|
|
|
// and may also be represented as an integer with the assumption that the value is an integral
|
|
|
|
// percentage out of 100. For instance, a runtime key lookup returning the value "42" would parse
|
|
|
|
// as a `FractionalPercent` whose numerator is 42 and denominator is HUNDRED.
|
|
|
|
message RuntimeFractionalPercent {
|
|
|
|
// Default value if the runtime value's for the numerator/denominator keys are not available.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
type.FractionalPercent default_value = 1 [(validate.rules).message = {required: true}];
|
|
|
|
|
|
|
|
// Runtime key for a YAML representation of a FractionalPercent.
|
|
|
|
string runtime_key = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Identifies a specific ControlPlane instance that Envoy is connected to.
|
|
|
|
message ControlPlane {
|
|
|
|
// An opaque control plane identifier that uniquely identifies an instance
|
|
|
|
// of control plane. This can be used to identify which control plane instance,
|
|
|
|
// the Envoy is connected to.
|
|
|
|
string identifier = 1;
|
|
|
|
}
|