emissary
emissary copied to clipboard
Host `mappingSelector` should apply also to `TCPMapping`
Please describe your use case / problem.
Currently a Host
can define a mappingSelector
to allow a Mapping
with the appropriate label to select automatically the corresponding Host
.
apiVersion: getambassador.io/v3alpha1
kind: Host
metadata:
name: api
namespace: emissary-system
spec:
hostname: api.my-domain.com
tlsSecret:
name: bogus-api-cert-secret
namespace: cert-manager
mappingSelector:
matchLabels:
emissary-host: api
---
apiVersion: getambassador.io/v3alpha1
kind: Mapping
metadata:
name: podinfo-default-get
namespace: test-podinfo
# Use a label to allow a Host to select this Mapping
labels:
emissary-host: api
spec:
prefix: /
method: GET
service: http://frontend-podinfo:9898
This doesn't apply to TCPMapping
though; if a TCPMapping
is configured with a label that could allow it to select a Host
, that Host
isn't selected automatically and a generic default Listener
is created in its place.
apiVersion: getambassador.io/v3alpha1
kind: Host
metadata:
name: ingest
namespace: emissary-system
spec:
hostname: ingest.my-domain.com
tlsSecret:
name: bogus-ingest-cert-secret
namespace: cert-manager
mappingSelector:
matchLabels:
emissary-host: ingest
---
apiVersion: getambassador.io/v3alpha1
kind: TCPMapping
metadata:
name: go-echo-default
namespace: test-go-echo
labels: # <-- does not
emissary-host: ingest # <-- work
spec:
port: 6443
service: tcp-echo-service:2701
Describe the solution you'd like
I would like to be able to define a Host
and mappingSelector
as usual, but allow a TCPMapping
with the appropriate label to select automatically the matching Host
.
Describe alternatives you've considered
The only solution other than leaving the host selection as is, would rely on creating either a separate selector (tcpMappingSelector
). I'm not sure about the practical implications or the effectiveness of this implementation proposal.
Additional context
N/A