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>). 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
On Sun, Feb 14, 2021 at 8:43 AM Roy Smith <roy(a)panix.com> wrote:
I'm running a django app under toolforge. I see there's already a
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 Davis Technical Engagement Wikimedia Foundation
Principal Software Engineer Boise, ID USA
[[m:User:BDavis_(WMF)]] irc: bd808
Wikimedia Cloud Services mailing list
Cloud(a)lists.wikimedia.org (formerly labs-l(a)lists.wikimedia.org)