I'm running a django app under toolforge. I see there's already a
X_REQUEST_ID: e9ec1899b09244939d22c2387db3b75a
header in the incoming request. That's totally cool, but I don't see it documented in the toolforge docs. is that something the toolforge infrastructure guarantees will be there?
On Sun, Feb 14, 2021 at 8:43 AM Roy Smith roy@panix.com wrote:
I'm running a django app under toolforge. I see there's already a
X_REQUEST_ID: e9ec1899b09244939d22c2387db3b75a
header in the incoming request. That's totally cool, but I don't see it documented in the toolforge docs. is that something the toolforge infrastructure guarantees will be there?
It took some digging around to find a good answer for this question. It turns out that the ingress system that we are using for Toolforge's Kubernetes cluster is adding it. A request id header is added when an existing header is not found in the inbound request as it traverses the ingress. Brooke tracked down https://github.com/kubernetes/ingress-nginx/issues/2546 upstream as a documented way that we could disable this default behavior if desired by the community or the Toolforge admins.
Bryan
Brian,
Thanks for taking the time to run that down for me!
I'm kind of surprised anybody would want to turn that off https://github.com/kubernetes/ingress-nginx/issues/2546 it's an incredibly useful feature. In every implementation of things like this that I've seen, the actual value is opaque, and if an earlier layer has added it, you just pass along the pre-existing value. Kubernetes does have a way of bending assumptions about how the universe works, however :-)
So, based on what you said, I'm going to assume it's not guaranteed to be there. I'm using django-log-request-id https://github.com/dabapps/django-log-request-id, which handles either case automatically, so turns out to be kind of a non-issue whether it is or not.
BTW, I implemented something like this years ago in haproxy (https://github.com/roysmith/haproxy-xuri https://github.com/roysmith/haproxy-xuri). The haproxy folks didn't pick up my patch, but I see they did eventually implement their own version.
On Feb 16, 2021, at 11:54 AM, Bryan Davis bd808@wikimedia.org wrote:
On Sun, Feb 14, 2021 at 8:43 AM Roy Smith roy@panix.com wrote:
I'm running a django app under toolforge. I see there's already a
X_REQUEST_ID: e9ec1899b09244939d22c2387db3b75a
header in the incoming request. That's totally cool, but I don't see it documented in the toolforge docs. is that something the toolforge infrastructure guarantees will be there?
It took some digging around to find a good answer for this question. It turns out that the ingress system that we are using for Toolforge's Kubernetes cluster is adding it. A request id header is added when an existing header is not found in the inbound request as it traverses the ingress. Brooke tracked down https://github.com/kubernetes/ingress-nginx/issues/2546 upstream as a documented way that we could disable this default behavior if desired by the community or the Toolforge admins.
Bryan
Bryan Davis Technical Engagement Wikimedia Foundation Principal Software Engineer Boise, ID USA [[m:User:BDavis_(WMF)]] irc: bd808
Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud