Cannot route to services that have long enough namespace or name #186
Milestone
Comments
|
Thanks for raising this issue, can you provide a sample service yaml and
I'll try to turn it into a unit test.
…On 26 January 2018 at 09:25, Alexander Brand ***@***.***> wrote:
When a service is created in a namespace that has a long enough name, or
when the service namespace + service name is long enough, any attempts to
connect to the service via Contour result in a "No healthy upstream"
response.
I believe the issue is that after translation, there is a mismatch between
the Cluster's EDS configuration and the Cluster Load Assignments. More
specifically, the ClusterName in the Cluster Load Assignment does not
match up with the ServiceName in the Cluster's EDS configuration, because
the ClusterName is being hashed when longer than 60 chars.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#186>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA6GEHeZOTMQ5GEl8YfTla5DA5w-Aks5tOP89gaJpZM4RtlT_>
.
|
|
Sure thing. I used the sample deployments documented in Contour, just with a long namespace: |
|
Thanks. I'll integrate that into the e2e tests i've been working on.
…On 26 January 2018 at 09:36, Alexander Brand ***@***.***> wrote:
Sure thing. I used the sample deployments documented in Contour, just with
a long namespace:
https://gist.github.com/alexbrand/fa4a715dc7e8e1dc5753955dde057ab1
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#186 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcAxk-YfPn2a0j5OiJiGM2AtAvc5HTks5tOQH8gaJpZM4RtlT_>
.
|
davecheney
added a commit
to davecheney/contour
that referenced
this issue
Jan 28, 2018
Updates projectcontour#186 Signed-off-by: Dave Cheney <[email protected]>
davecheney
added a commit
to davecheney/contour
that referenced
this issue
Jan 28, 2018
Updates projectcontour#186 Signed-off-by: Dave Cheney <[email protected]>
davecheney
added a commit
to davecheney/contour
that referenced
this issue
Jan 28, 2018
Updates projectcontour#186 Signed-off-by: Dave Cheney <[email protected]>
davecheney
added a commit
to davecheney/contour
that referenced
this issue
Jan 28, 2018
Updates projectcontour#186 Signed-off-by: Dave Cheney <[email protected]>
Merged
davecheney
added a commit
that referenced
this issue
Jan 31, 2018
Updates #186 This PR fixes a condition whereby endpoints (clusterloadassignments) could remain in the EDS cache after the endpoint has been removed from the apiserver. This was partially fixed by #187, which dealt with the case of accidentally hashing the servicename field of the clusterloadassignment, however hashname was still being applied when generating the key to remove the endpoint object from the EDS cache. Apart from leaving unreferenced, as the endpoints' service would have been removed also, entries in the EDS cache this bug was probably benign so this is not critical to backport to 0.3.x. Signed-off-by: Dave Cheney <[email protected]>
sunjayBhatia
pushed a commit
that referenced
this issue
Jan 30, 2023
Signed-off-by: Daneyon Hansen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a service is created in a namespace that has a long enough name, or when the service namespace + service name is long enough, any attempts to connect to the service via Contour result in a "No healthy upstream" response.
I believe the issue is that after translation, there is a mismatch between the Cluster's EDS configuration and the Cluster Load Assignments. More specifically, the
ClusterNamein the Cluster Load Assignment does not match up with theServiceNamein the Cluster's EDS configuration, because theClusterNameis being hashed when longer than 60 chars.The text was updated successfully, but these errors were encountered: