--- 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.

## Services

### AggregatedMeshConfigService

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.

## Types

### Client

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).

Field | Type | Description
--- | --- | ---
`id` | `string` | An opaque identifier for the MCP client.
`metadata` | `google.protobuf.Struct` | Opaque metadata extending the client identifier.

### Envelope

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.

Field | Type | Description
--- | --- | ---
`metadata` | `Metadata` | Common metadata describing the resource.
`resource` | `google.protobuf.Any` | The resource itself.

### MeshConfigRequest

A MeshConfigRequest requests a set of versioned resources of the same type for a given client.

Field | Type | Description
--- | --- | ---
`versionInfo` | `string` | The versioninfo provided in the request messages will be the versioninfo received with the most recent successfully processed response or empty on the first request. It is expected that no new request is sent after a response is received until the client instance is ready to ACK/NACK the new configuration. ACK/NACK takes place by returning the new API config version as applied or the previous API config version respectively. Each type_url (see below) has an independent version associated with it.
`client` | `Client` | The client making the request.
`typeUrl` | `string` | Type of the resource that is being requested, e.g. “type.googleapis.com/istio.io.networking.v1alpha3.VirtualService”.
`responseNonce` | `string` | The nonce corresponding to MeshConfigResponse being ACK/NACKed. See above discussion on version_info and the MeshConfigResponse nonce comment. This may be empty if no nonce is available, e.g. at startup.
`errorDetail` | `google.rpc.Status` | This is populated when the previous MeshConfigResponse failed to update configuration. The message field in error_details provides the client internal exception related to the failure. It is only intended for consumption during manual debugging, the string provided is not guaranteed to be stable across client versions.

### MeshConfigResponse

A MeshConfigResponse delivers a set of versioned resources of the same type in response to a MeshConfigRequest.

Field | Type | Description
--- | --- | ---
`versionInfo` | `string` | The version of the response data.
`envelopes` | `Envelope[]` | The response resources wrapped in the common MCP Envelope message.
`typeUrl` | `string` | Type URL for resources wrapped in the provided envelope(s). This must be consistent with the type_url in the wrapper messages if envelopes is non-empty.
`nonce` | `string` | The nonce provides a way to explicitly ack a specific MeshConfigResponse in a following MeshConfigRequest. Additional messages may have been sent by client to the management server for the previous version on the stream prior to this MeshConfigResponse, that were unprocessed at response send time. The nonce allows the management server to ignore any further MeshConfigRequests for the previous version until a MeshConfigRequest bearing the nonce.

### Metadata

Metadata information that all resources within the Mesh Configuration Protocol must have.

Field | Type | Description
--- | --- | ---
`name` | `string` | The name of the resource. It is unique within the context of a resource type and the origin server of the resource. The resource type is identified by the TypeUrl of the resource field of the Envelope message.

### google.rpc.Status

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:

- Simple to use and understand for most users
- Flexible enough to meet unexpected needs

#### Overview

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.

#### Language mapping

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.

#### Other uses

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.

Field | Type | Description
--- | --- | ---
`code` | `int32` | The status code, which should be an enum value of google.rpc.Code.
`message` | `string` | A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the google.rpc.Status.details field, or localized by the client.
`details` | `google.protobuf.Any[]` | A list of messages that carry the error details. There is a common set of message types for APIs to use.