Brian,

Thanks for taking the time to run that down for me!

I'm kind of surprised anybody would want to turn that off  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, 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 <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