envoy.api.v2github.com/solo-io/solo-kit/api/external/envoy/api/v2/discovery.proto

Package : envoy.api.v2

Top

github.com/solo-io/solo-kit/api/external/envoy/api/v2/discovery.proto

Table of Contents

• DeltaDiscoveryRequest
• DeltaDiscoveryRequest.InitialResourceVersionsEntry
• DeltaDiscoveryResponse
• DiscoveryRequest
• DiscoveryResponse
• Resource

DeltaDiscoveryRequest

DeltaDiscoveryRequest and DeltaDiscoveryResponse are used in a new gRPC endpoint for Delta xDS.

With Delta xDS, the DeltaDiscoveryResponses do not need to include a full snapshot of the tracked resources. Instead, DeltaDiscoveryResponses are a diff to the state of a xDS client. In Delta XDS there are per-resource versions, which allow tracking state at the resource granularity. An xDS Delta session is always in the context of a gRPC bidirectional stream. This allows the xDS server to keep track of the state of xDS clients connected to it.

In Delta xDS the nonce field is required and used to pair DeltaDiscoveryResponse to a DeltaDiscoveryRequest ACK or NACK. Optionally, a response message level system_version_info is present for debugging purposes only.

DeltaDiscoveryRequest plays two independent roles. Any DeltaDiscoveryRequest can be either or both of: [1] informing the server of what resources the client has gained/lost interest in (using resource_names_subscribe and resource_names_unsubscribe), or [2] (N)ACKing an earlier resource update from the server (using response_nonce, with presence of error_detail making it a NACK). Additionally, the first message (for a given type_url) of a reconnected gRPC stream has a third role: informing the server of the resources (and their versions) that the client already possesses, using the initial_resource_versions field.

As with state-of-the-world, when multiple resource types are multiplexed (ADS), all requests/acknowledgments/updates are logically walled off by type_url: a Cluster ACK exists in a completely separate world from a prior Route NACK. In particular, initial_resource_versions being sent at the "start" of every gRPC stream actually entails a message for each type_url, each with its own initial_resource_versions.

Unlike state-of-the-world xDS, an empty resource_names_subscribe or resource_names_unsubscribe list simply means that no resources are to be added or removed to the resource list. Like state-of-the-world xDS, the server must send updates for all tracked resources, but can also send updates for resources the client has not subscribed to.

NOTE: the server must respond with all resources listed in resource_names_subscribe, even if it believes the client has the most recent version of them. The reason: the client may have dropped them, but then regained interest before it had a chance to send the unsubscribe message. See DeltaSubscriptionStateTest.RemoveThenAdd.

These two fields can be set in any DeltaDiscoveryRequest, including ACKs and initial_resource_versions.

A list of Resource names to add to the list of tracked resources. | | resource_names_unsubscribe | []string | repeated | A list of Resource names to remove from the list of tracked resources. | | initial_resource_versions | []DeltaDiscoveryRequest.InitialResourceVersionsEntry | repeated | Informs the server of the versions of the resources the xDS client knows of, to enable the client to continue the same logical xDS session even in the face of gRPC stream reconnection. It will not be populated: [1] in the very first stream of a session, since the client will not yet have any resources, [2] in any message after the first in a stream (for a given type_url), since the server will already be correctly tracking the client's state. (In ADS, the first message of each type_url of a reconnected stream populates this map.) The map's keys are names of xDS resources known to the xDS client. The map's values are opaque resource versions. | | response_nonce | string | | When the DeltaDiscoveryRequest is a ACK or NACK message in response to a previous DeltaDiscoveryResponse, the response_nonce must be the nonce in the DeltaDiscoveryResponse. Otherwise (unlike in DiscoveryRequest) response_nonce must be omitted. | | error_detail | google.rpc.Status | | This is populated when the previous DiscoveryResponse (envoy_api_msg_DiscoveryResponse) failed to update configuration. The message field in error_details provides the Envoy internal exception related to the failure. |

DeltaDiscoveryRequest.InitialResourceVersionsEntry

DeltaDiscoveryResponse

DiscoveryRequest

A DiscoveryRequest requests a set of versioned resources of the same type for a given Envoy node on some API.

DiscoveryResponse

• –terminate-on-canary-transition-failure. When set, Envoy is able to terminate if it detects that configuration is stuck at canary. Consider this example sequence of updates:
  • Management server applies a canary config successfully.
  • Management server rolls back to a production config.
  • Envoy rejects the new production config. Since there is no sensible way to continue receiving configuration updates, Envoy will then terminate and apply production config from a clean slate.
• –dry-run-canary. When set, a canary response will never be applied, only validated via a dry run. | | type_url | string | | Type URL for resources. Identifies the xDS API when muxing over ADS. Must be consistent with the type_url in the 'resources' repeated Any (if non-empty). | | nonce | string | | For gRPC based subscriptions, the nonce provides a way to explicitly ack a specific DiscoveryResponse in a following DiscoveryRequest. Additional messages may have been sent by Envoy to the management server for the previous version on the stream prior to this DiscoveryResponse, that were unprocessed at response send time. The nonce allows the management server to ignore any further DiscoveryRequests for the previous version until a DiscoveryRequest bearing the nonce. The nonce is optional and is not required for non-stream based xDS implementations. | | control_plane | core.ControlPlane | | [#not-implemented-hide:] The control plane instance that sent the response. |

Resource