-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Envoy making load balancing decisions based on request headers #343
Labels
Comments
rshriram
pushed a commit
to rshriram/envoy
that referenced
this issue
Oct 30, 2018
…oxy#343) * ApiManager uses ConfigManager to download the service config * Removed uncessary header file inclusion * Moved all initialization into Init() * Reverted copyright year to 2016 * Reverted copyright year to 2016 * Added a local auto variable for ServiceContext creation * Fixed backward compatibility * Added the rollout_strategy check * Added service_config argument to ConfigManager * Moved service_config_ variable to GlobalContext class * Fixed code formatting * Reverted storing service_config in GlobalContext * Renamed and changed data type of const * Moved callback function argument from constructor to Init
This is already possible via different mechanisms. Closing in favor of more specific issues/requests. |
jplevyak
referenced
this issue
in jplevyak/envoy
Jan 22, 2020
Signed-off-by: Kuat Yessenov <[email protected]>
jpsim
pushed a commit
that referenced
this issue
Nov 28, 2022
Implements a new `EnvoyBuilder` type which consumers will now use to create new instances of `Envoy` going forward (rather than initializing it directly). This supports the following using a builder pattern: - Adding log levels - Adding configuration options that were previously part of `Configuration` - Specifying a YAML file override for consumers who may want to use a custom configuration instead of the default template - Creating an instance of `Envoy` with these configurations using an underlying `EnvoyEngine` implementation - Injecting mock engines so we don't start real instances of Envoy when testing Example usage: ```swift let envoy = try EnvoyBuilder() .addStatsFlushSeconds(30) .addDNSRefreshSeconds(30) .addLogLevel(.trace) .build() ``` Signed-off-by: Michael Rebello <[email protected]> Signed-off-by: JP Simard <[email protected]>
jpsim
pushed a commit
that referenced
this issue
Nov 29, 2022
Implements a new `EnvoyBuilder` type which consumers will now use to create new instances of `Envoy` going forward (rather than initializing it directly). This supports the following using a builder pattern: - Adding log levels - Adding configuration options that were previously part of `Configuration` - Specifying a YAML file override for consumers who may want to use a custom configuration instead of the default template - Creating an instance of `Envoy` with these configurations using an underlying `EnvoyEngine` implementation - Injecting mock engines so we don't start real instances of Envoy when testing Example usage: ```swift let envoy = try EnvoyBuilder() .addStatsFlushSeconds(30) .addDNSRefreshSeconds(30) .addLogLevel(.trace) .build() ``` Signed-off-by: Michael Rebello <[email protected]> Signed-off-by: JP Simard <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
One use case is that internal service might want to set specific header so that Envoy will route request to canary only nodes.
We might find other use cases, make header to be
x-envoy-lb-hint
and use various types of hints in chooseHost logic.The text was updated successfully, but these errors were encountered: