You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following configuration attempts to use labels to associate the quote-backend-foo Mapping only with foo.example.com, and quote-backend-bar only with bar.example.com:
Since the two Mappings have different host labels, they will associate with different Hosts
and should not be placed in the same canary group. However, as of Emissary 2.2.2, the canary-group
logic doesn't pay attention to labels, so the two Mappings will (wrongly) be placed in the same
canary group. Since Envoy-config generation operates on groups rather than on individual Mappings,
the effect here is that https://foo.example.com/test/ will be correctly routed, but https://bar.example.com/test/ will 404.
As an additional constraint, consider the same Hosts above, but these two Mappings:
These Mappings should be placed in the same canary group, since the Hosts don't differentiate
based on the irrelevant-label label. So we mustn't look at every label -- only the ones that
the Hosts actually care about matter.
To work around this, you can either:
Give the two Mappings a precedence with different values so that they can't be canaried together, or
Use the hostname rather than labels.
The text was updated successfully, but these errors were encountered:
If two mappings have different host labels but share the same prefix, then they should not be placed in the same canary group. Previously, labels were not taken into account when grouping mappings into canary groups, which caused mappings sharing the same prefix to be part of the same canary group when using host labels (hostname or host field was not specified in the mapping).
In order to solve this, we update the mapping group_id logic to incorporate host selector labels. This means that the mappings are grouped based on the following criteria:
- HTTP method
- Prefix
- Headers
- Query parameters
- Host labels
- Precedence
Because this affects only how mappings are grouped, the following behavior is retained:
- hostname, host, and :authority header fields take precendence over host labels for the purposes of grouping.
- If hostname, host, and/or :authority header fields are specified along with host labels, then they must match before they can be associated.
- A canary group can be associated with multiple Hosts based on selector labels.
Fixes#4170.
Signed-off-by: Hamzah Qudsi <hqudsi@datawire.io>
The following configuration attempts to use labels to associate the
quote-backend-foo
Mapping
only withfoo.example.com
, andquote-backend-bar
only withbar.example.com
:Since the two
Mapping
s have differenthost
labels, they will associate with differentHost
sand should not be placed in the same canary group. However, as of Emissary 2.2.2, the canary-group
logic doesn't pay attention to labels, so the two
Mapping
s will (wrongly) be placed in the samecanary group. Since Envoy-config generation operates on groups rather than on individual
Mapping
s,the effect here is that
https://foo.example.com/test/
will be correctly routed, buthttps://bar.example.com/test/
will 404.As an additional constraint, consider the same
Host
s above, but these twoMapping
s:These
Mapping
s should be placed in the same canary group, since theHost
s don't differentiatebased on the
irrelevant-label
label. So we mustn't look at every label -- only the ones thatthe
Host
s actually care about matter.To work around this, you can either:
Mapping
s aprecedence
with different values so that they can't be canaried together, orhostname
rather than labels.The text was updated successfully, but these errors were encountered: