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
{{ message }}
This repository has been archived by the owner on Jun 14, 2018. It is now read-only.
What happened:
I have a composite microservice (foobar) that is calling 2 nested atomic services (foo and bar) and all 3 services are part of my istio service mesh. I set up a Route Rule (see below) with a destination of bar and a match configuration based on source and request header. I am expecting that if I send a curl request to my ingress controller such as the following:
I should see that the http request from foobar to bar will be directed to v2 of bar. However, I am unable to ever get that match rule to work. I have tried making curl requests directly to ingress controller, as well as by getting a shell into one of the other pods (e.g. foo or bar) and submitting request from there, but I get the same outcome.
If I remove the request headers rule and just go with the match on source, the route rule works as expected. I am assuming that the request headers are not being passed from foobar down to bar via Envoy?
The actual implementation of my services is Java and foobar is making http requests to foo and bar using Spring RestTemplate. The urls that I have configured for those http calls are http://foo:8080/foo and http://bar:8080/bar respectively (see foobar.yaml below for my service configs).
As I have mentioned above, all the route rules I have set up previously based on source and/or version from foobar to the nested services have all worked as expected. It is just the request header based rules that seem to not be working.
It should be noted that if I set up a similar rule (using request headers) on one of the atomic services, everything works as expected.
@my3sons commented on Sun Oct 15 2017
Is this a BUG or FEATURE REQUEST?:
BUG
Did you review existing epics or issues to identify if this already being worked on? (please try to add the correct labels and epics):
Bug:
Y
What Version of Istio and Kubernetes are you using, where did you get Istio from, Installation details
Is Istio Auth enabled or not ?
NO AUTH
What happened:
I have a composite microservice (foobar) that is calling 2 nested atomic services (foo and bar) and all 3 services are part of my istio service mesh. I set up a Route Rule (see below) with a destination of bar and a match configuration based on source and request header. I am expecting that if I send a curl request to my ingress controller such as the following:
curl -s http://10.111.233.201:80/foobar --header "clientid:esp"
I should see that the http request from foobar to bar will be directed to v2 of bar. However, I am unable to ever get that match rule to work. I have tried making curl requests directly to ingress controller, as well as by getting a shell into one of the other pods (e.g. foo or bar) and submitting request from there, but I get the same outcome.
If I remove the request headers rule and just go with the match on source, the route rule works as expected. I am assuming that the request headers are not being passed from foobar down to bar via Envoy?
The actual implementation of my services is Java and foobar is making http requests to foo and bar using Spring RestTemplate. The urls that I have configured for those http calls are http://foo:8080/foo and http://bar:8080/bar respectively (see foobar.yaml below for my service configs).
As I have mentioned above, all the route rules I have set up previously based on source and/or version from foobar to the nested services have all worked as expected. It is just the request header based rules that seem to not be working.
It should be noted that if I set up a similar rule (using request headers) on one of the atomic services, everything works as expected.
My Route Rule
foobar.yaml
The text was updated successfully, but these errors were encountered: