--- title: istio.mcp.v1alpha1 layout: protoc-gen-docs generator: protoc-gen-docs number_of_entries: 7 ---
This package defines the common, core types used by the Mesh Configuration Protocol.
The aggregated mesh configuration services allow a single management server, via a single gRPC stream, to deliver all API updates.
rpc StreamAggregatedResources(MeshConfigRequest) returns (MeshConfigResponse)
StreamAggregatedResources provides the ability to carefully sequence updates across multiple resource types. A single stream is used with multiple independent MeshConfigRequest / MeshConfigResponses sequences multiplexed via the type URL.
Identifies a specific MCP client instance. The client identifier is presented to the management server, which may use this identifier to distinguish per client configuration for serving. This information is not authoriative. Authoritative identity should come from the underlying transport layer (e.g. rpc credentials).
Envelope for a configuration resource as transferred via the Mesh Configuration Protocol. Each envelope is made up of common metadata, and a type-specific resource payload.
A MeshConfigRequest requests a set of versioned resources of the same type for a given client.
A MeshConfigResponse delivers a set of versioned resources of the same type in response to a MeshConfigRequest.
Metadata information that all resources within the Mesh Configuration Protocol must have.
The Status
type defines a logical error model that is suitable for different
programming environments, including REST APIs and RPC APIs. It is used by
gRPC. The error model is designed to be:
The Status
message contains three pieces of data: error code, error message,
and error details. The error code should be an enum value of
google.rpc.Code, but it may accept additional error codes if needed. The
error message should be a developer-facing English message that helps
developers understand and resolve the error. If a localized user-facing
error message is needed, put the localized message in the error details or
localize it in the client. The optional error details may contain arbitrary
information about the error. There is a predefined set of error detail types
in the package google.rpc
that can be used for common error conditions.
The Status
message is the logical representation of the error model, but it
is not necessarily the actual wire format. When the Status
message is
exposed in different client libraries and different wire protocols, it can be
mapped differently. For example, it will likely be mapped to some exceptions
in Java, but more likely mapped to some error codes in C.
The error model and the Status
message can be used in a variety of
environments, either with or without APIs, to provide a
consistent developer experience across different environments.
Example uses of this error model include:
Partial errors. If a service needs to return partial errors to the client,
it may embed the Status
in the normal response to indicate the partial
errors.
Workflow errors. A typical workflow has multiple steps. Each step may
have a Status
message for error reporting.
Batch operations. If a client uses batch request and batch response, the
Status
message should be used directly inside batch response, one for
each error sub-response.
Asynchronous operations. If an API call embeds asynchronous operation
results in its response, the status of those operations should be
represented directly using the Status
message.
Logging. If some API errors are stored in logs, the message Status
could
be used directly after any stripping needed for security/privacy reasons.