healthv3grpc

type HealthDiscoveryServiceClient interface {
	//  1. Envoy starts up and if its can_healthcheck option in the static
	//     bootstrap config is enabled, sends HealthCheckRequest to the management
	//     server. It supplies its capabilities (which protocol it can health check
	//     with, what zone it resides in, etc.).
	//  2. In response to (1), the management server designates this Envoy as a
	//     healthchecker to health check a subset of all upstream hosts for a given
	//     cluster (for example upstream Host 1 and Host 2). It streams
	//     HealthCheckSpecifier messages with cluster related configuration for all
	//     clusters this Envoy is designated to health check. Subsequent
	//     HealthCheckSpecifier message will be sent on changes to:
	//     a. Endpoints to health checks
	//     b. Per cluster configuration change
	//  3. Envoy creates a health probe based on the HealthCheck config and sends
	//     it to endpoint(ip:port) of Host 1 and 2. Based on the HealthCheck
	//     configuration Envoy waits upon the arrival of the probe response and
	//     looks at the content of the response to decide whether the endpoint is
	//     healthy or not. If a response hasn't been received within the timeout
	//     interval, the endpoint health status is considered TIMEOUT.
	//  4. Envoy reports results back in an EndpointHealthResponse message.
	//     Envoy streams responses as often as the interval configured by the
	//     management server in HealthCheckSpecifier.
	//  5. The management Server collects health statuses for all endpoints in the
	//     cluster (for all clusters) and uses this information to construct
	//     EndpointDiscoveryResponse messages.
	//  6. Once Envoy has a list of upstream endpoints to send traffic to, it load
	//     balances traffic to them without additional health checking. It may
	//     use inline healthcheck (i.e. consider endpoint UNHEALTHY if connection
	//     failed to a particular endpoint to account for health status propagation
	//     delay between HDS and EDS).
	//
	// By default, can_healthcheck is true. If can_healthcheck is false, Cluster
	// configuration may not contain HealthCheck message.
	// TODO(htuch): How is can_healthcheck communicated to CDS to ensure the above
	// invariant?
	// TODO(htuch): Add @amb67's diagram.
	StreamHealthCheck(ctx context.Context, opts ...grpc.CallOption) (HealthDiscoveryService_StreamHealthCheckClient, error)
	// TODO(htuch): Unlike the gRPC version, there is no stream-based binding of
	// request/response. Should we add an identifier to the HealthCheckSpecifier
	// to bind with the response?
	FetchHealthCheck(ctx context.Context, in *v3.HealthCheckRequestOrEndpointHealthResponse, opts ...grpc.CallOption) (*v3.HealthCheckSpecifier, error)
}

type HealthDiscoveryServiceServer interface {
	//  1. Envoy starts up and if its can_healthcheck option in the static
	//     bootstrap config is enabled, sends HealthCheckRequest to the management
	//     server. It supplies its capabilities (which protocol it can health check
	//     with, what zone it resides in, etc.).
	//  2. In response to (1), the management server designates this Envoy as a
	//     healthchecker to health check a subset of all upstream hosts for a given
	//     cluster (for example upstream Host 1 and Host 2). It streams
	//     HealthCheckSpecifier messages with cluster related configuration for all
	//     clusters this Envoy is designated to health check. Subsequent
	//     HealthCheckSpecifier message will be sent on changes to:
	//     a. Endpoints to health checks
	//     b. Per cluster configuration change
	//  3. Envoy creates a health probe based on the HealthCheck config and sends
	//     it to endpoint(ip:port) of Host 1 and 2. Based on the HealthCheck
	//     configuration Envoy waits upon the arrival of the probe response and
	//     looks at the content of the response to decide whether the endpoint is
	//     healthy or not. If a response hasn't been received within the timeout
	//     interval, the endpoint health status is considered TIMEOUT.
	//  4. Envoy reports results back in an EndpointHealthResponse message.
	//     Envoy streams responses as often as the interval configured by the
	//     management server in HealthCheckSpecifier.
	//  5. The management Server collects health statuses for all endpoints in the
	//     cluster (for all clusters) and uses this information to construct
	//     EndpointDiscoveryResponse messages.
	//  6. Once Envoy has a list of upstream endpoints to send traffic to, it load
	//     balances traffic to them without additional health checking. It may
	//     use inline healthcheck (i.e. consider endpoint UNHEALTHY if connection
	//     failed to a particular endpoint to account for health status propagation
	//     delay between HDS and EDS).
	//
	// By default, can_healthcheck is true. If can_healthcheck is false, Cluster
	// configuration may not contain HealthCheck message.
	// TODO(htuch): How is can_healthcheck communicated to CDS to ensure the above
	// invariant?
	// TODO(htuch): Add @amb67's diagram.
	StreamHealthCheck(HealthDiscoveryService_StreamHealthCheckServer) error
	// TODO(htuch): Unlike the gRPC version, there is no stream-based binding of
	// request/response. Should we add an identifier to the HealthCheckSpecifier
	// to bind with the response?
	FetchHealthCheck(context.Context, *v3.HealthCheckRequestOrEndpointHealthResponse) (*v3.HealthCheckSpecifier, error)
}

type HealthDiscoveryService_StreamHealthCheckClient interface {
	Send(*v3.HealthCheckRequestOrEndpointHealthResponse) error
	Recv() (*v3.HealthCheckSpecifier, error)
	grpc.ClientStream
}

type HealthDiscoveryService_StreamHealthCheckServer interface {
	Send(*v3.HealthCheckSpecifier) error
	Recv() (*v3.HealthCheckRequestOrEndpointHealthResponse, error)
	grpc.ServerStream
}

type UnimplementedHealthDiscoveryServiceServer struct {
}

type UnsafeHealthDiscoveryServiceServer interface {
	// contains filtered or unexported methods
}