diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000000..1db2bfabfe --- /dev/null +++ b/.gitattributes @@ -0,0 +1,2 @@ +*.pb.go linguist-generated=true +*.pb.html linguist-generated=true diff --git a/mcp/v1alpha1/istio.mcp.v1alpha1.pb.html b/mcp/v1alpha1/istio.mcp.v1alpha1.pb.html index 48999418da..bcee77a76a 100644 --- a/mcp/v1alpha1/istio.mcp.v1alpha1.pb.html +++ b/mcp/v1alpha1/istio.mcp.v1alpha1.pb.html @@ -2,7 +2,7 @@ title: istio.mcp.v1alpha1 layout: protoc-gen-docs generator: protoc-gen-docs -number_of_entries: 9 +number_of_entries: 13 ---
This package defines the common, core types used by the Mesh Configuration Protocol.
@@ -27,76 +27,31 @@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).
+Service where the source is the gRPC client. The source is responsible for +initiating connections and opening streams.
-| Field | -Type | -Description | -
|---|---|---|
id |
-string |
-
- An opaque identifier for the MCP client. - - |
-
metadata |
-google.protobuf.Struct |
-
- Opaque metadata extending the client identifier. +
+The source, acting as gRPC client, establishes a new resource stream +with the sink. The sink sends RequestResources message to and +receives Resources messages from the source. - |
-
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. +Service where the sink is the gRPC client. The sink is responsible for +initiating connections and opening streams. - |
-
resource |
-google.protobuf.Any |
-
- The resource itself. +
+The sink, acting as gRPC client, establishes a new resource stream +with the source. The sink sends RequestResources message to +and receives Resources messages from the source. - |
-
IncrementalMeshConfigRequest are be sent in 2 situations:
@@ -118,11 +73,11 @@clientClientsinkNodeSinkNodeThe client making the request.
+The sink node making the request.
envelopesEnvelope[]resourcesResource[]The response resources wrapped in the common MCP Envelope +
The response resources wrapped in the common MCP Resource message. These are typed resources that match the type url in the IncrementalMeshConfigRequest.
@@ -265,11 +220,11 @@clientClientsinkNodeSinkNodeThe client making the request.
+The sink node making the request.
envelopesEnvelope[]resourcesResource[]The response resources wrapped in the common MCP Envelope +
The response resources wrapped in the common MCP Resource message.
typeUrlstringType URL for resources wrapped in the provided envelope(s). This +
Type URL for resources wrapped in the provided resources(s). This must be consistent with the type_url in the wrapper messages if -envelopes is non-empty.
+resources is non-empty.namestringThe 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.
+Fully qualified name of the resource. Unique in context of a collection.
+ +The fully qualified name consists of a directory and basename. The directory identifies +the resources location in a resource hierarchy. The basename identifies the specific +resource name within the context of that directory.
+ +The directory and basename are composed of one or more segments. Segments must be +valid DNS labels. “/” is the delimiter between +segments
+ +The rightmost segment is the basename. All segments to the +left of the basename form the directory. Segments moving towards the left +represent higher positions in the resource hierarchy, similar to reverse +DNS notation. e.g.
+ +/
An empty directory indicates a resource that is located at the root of the +hierarchy, e.g.
+ +/
On Kubernetes the resource hierarchy is two-levels: namespaces and +cluster-scoped (i.e. global).
+ +Namespace resources fully qualified name is of the form:
+ +”/
Cluster scoped resources are located at the root of the hierarchy and are of the form:
+ +”/
versionstringThe resource level version. It allows MCP to track the state of -individual resources.
+Resource version. This is used to determine when resources change across +resource updates. It should be treated as opaque by consumers/sinks.
+ +labelsmap<string, string>Map of string keys and values that can be used to organize and categorize +resources within a collection.
+ +annotationsmap<string, string>Map of string keys and values that can be used by source and sink to communicate +arbitrary metadata about this resource.
+ +A RequestResource can be sent in two situations:
+ +Initial message in an MCP bidirectional change stream +as an ACK or NACK response to a previous Resources. In +this case the responsenonce is set to the nonce value +in the Resources. ACK/NACK is determined by the presence +of errordetail.
+ +| Field | +Type | +Description | +
|---|---|---|
sinkNode |
+SinkNode |
+
+ The sink node making the request. + + |
+
collection |
+string |
+
+ Type of resource collection that is being requested, e.g. + +istio/networking/v1alpha3/VirtualService
+k8s/ |
+
initialResourceVersions |
+map<string, string> |
+
+ When the RequestResources is the first in a stream, the initialresourceversions must +be populated. Otherwise, initialresourceversions must be omitted. The keys are the +resources names of the MCP resources known to the MCP client. The values in the map +are the associated resource level version info. + + |
+
responseNonce |
+string |
+
+ When the RequestResources is an ACK or NACK message in response to a previous RequestResources, +the responsenonce must be the nonce in the RequestResources. Otherwise responsenonce must +be omitted. + + |
+
errorDetail |
+google.rpc.Status |
+
+ This is populated when the previously received resources could not be applied +The message field in error_details provides the source internal error +related to the failure. + + |
+
Resource as transferred via the Mesh Configuration Protocol. Each +resource is made up of common metadata, and a type-specific resource payload.
+ +| Field | +Type | +Description | +
|---|---|---|
metadata |
+Metadata |
+
+ Common metadata describing the resource. + + |
+
body |
+google.protobuf.Any |
+
+ The primary payload for the resource. + + |
+
Resources do not need to include a full snapshot of the tracked +resources. Instead they are a diff to the state of a MCP client. +Per resource versions allow sources and sinks to track state at +the resource granularity. An MCP incremental session is always +in the context of a gRPC bidirectional stream. This allows the +MCP source to keep track of the state of MCP sink connected to +it.
+ +In Incremental MCP the nonce field is required and used to pair +Resources to an RequestResources ACK or NACK.
+ +| Field | +Type | +Description | +
|---|---|---|
systemVersionInfo |
+string |
+
+ The version of the response data (used for debugging). + + |
+
collection |
+string |
+
+ Type of resource collection that is being requested, e.g. + +istio/networking/v1alpha3/VirtualService
+k8s/ |
+
resources |
+Resource[] |
+
+ The response resources wrapped in the common MCP Resource message. +These are typed resources that match the type url in the +RequestResources message. + + |
+
removedResources |
+string[] |
+
+ Names of resources that have been deleted and to be +removed from the MCP sink node. Removed resources for missing +resources can be ignored. + + |
+
nonce |
+string |
+
+ Required. The nonce provides a way for RequestChange to uniquely +reference a RequestResources. + + |
+
Identifies a specific MCP sink node instance. The node identifier is +presented to the resource source, which may use this identifier +to distinguish per sink configuration for serving. This +information is not authoritative. Authoritative identity should come +from the underlying transport layer (e.g. rpc credentials).
+ +| Field | +Type | +Description | +
|---|---|---|
id |
+string |
+
+ An opaque identifier for the MCP node. + + |
+
annotations |
+map<string, string> |
+
+ Opaque annotations extending the node identifier. |