Description: This PR (which picks up work started on #1567) adds outlier detection to all configured clusters.

The main objective of this configuration is to drain connections that are perceived to be "dead" so that the cluster is forced to establish a new connection for future streams.

Currently the outlier detector will not eject already ejected hosts. And host ejection is what causes connection drain. In mobile, the desire is not to keep hosts ejected, but rather to cycle the underlying upstream connections. Hence the short base/max ejection time and the the tight unejection interval. The unejection interval is not any tighter because to balance timer churn.

The idea with the current configuration is that most, if not all "dead" connections will be reaped without having any adverse performance issues. Lyft will deploy and analyze production data to further tune the configuration. If ultimately different detector behavior (drain connections even if host is ejected) is desired, we can work to add to upstream envoy.

Risk Level:
Testing: This configuration was tested with the existing example apps pointed to a server that continuously returns 503. Expected host ejection, connection drain, host unejection behavior was observed.

Signed-off-by: Jose Nino jnino@lyft.com
Co-authored-by: Mike Schore mike.schore@gmail.com
Signed-off-by: JP Simard <jp@jpsim.com>

Description: This PR (which picks up work started on #1567) adds outlier detection to all configured clusters.

The main objective of this configuration is to drain connections that are perceived to be "dead" so that the cluster is forced to establish a new connection for future streams.

Currently the outlier detector will not eject already ejected hosts. And host ejection is what causes connection drain. In mobile, the desire is not to keep hosts ejected, but rather to cycle the underlying upstream connections. Hence the short base/max ejection time and the the tight unejection interval. The unejection interval is not any tighter because to balance timer churn.

The idea with the current configuration is that most, if not all "dead" connections will be reaped without having any adverse performance issues. Lyft will deploy and analyze production data to further tune the configuration. If ultimately different detector behavior (drain connections even if host is ejected) is desired, we can work to add to upstream envoy.

Risk Level:
Testing: This configuration was tested with the existing example apps pointed to a server that continuously returns 503. Expected host ejection, connection drain, host unejection behavior was observed.

Signed-off-by: Jose Nino jnino@lyft.com
Co-authored-by: Mike Schore mike.schore@gmail.com
Signed-off-by: JP Simard <jp@jpsim.com>

**Description**

This fixes the inconsistency for embeddings in the span usage in
translators.

**Related Issues/PRs (if applicable)**
Preparation for #90
Follow up on #1565

---------

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>

#1568)

**Description**

This fixes the inconsistency of span usage by image gen and rerank
translators

**Related Issues/PRs (if applicable)**
Preparation for #90 
Follow up on #1565 #1567

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>