lostluck commented on issue #24470:
URL: https://github.com/apache/beam/issues/24470#issuecomment-1335654582
So there are two issues here.
1. Turns out that debian-bullseye as a base container might not have the
latest and greatest glibc (this is WAI probably, due to debian's ethos).
2. Boot loader container messages aren't discoverable.
The first has a few options: Option 1: Custom containers. That's always an
option and lets any container be used as the worker container, as long as the
entrypoint is the bootloader to handle the rest of the container contract.
Option 2: Disable linking by turning off CGO, as already described.
We aren't likely to move off of debian as the container base anytime soon,
but we could expand
https://beam.apache.org/documentation/sdks/go-cross-compilation/ with a bit of
this information.
The second is that we had to *hunt* for the root cause. That's never good.
It hurts everyone. Ideally, the error is elevated properly, and tells you where
to find answers.
In this case, since we have dedicated loaders per language, they could point
to relevant places on the beam site, like
https://beam.apache.org/documentation/sdks/go-cross-compilation/ or similar.
That's where the documentation for this should live. As for how to elevate it.
---------
All uses of the Beam Go SDK use the same containers, so the fix would be in
the repo.
In principle, the boot loader could connect to the FnAPI logging service to
make the failure announcement. That should elevate it in the Dataflow logs (and
all other SDK uses with a FnAPI). It's not entirely clear to me why we don't
already beyond it's not been needed before.
So the initial arg log is here:
https://github.com/apache/beam/blob/master/sdks/go/container/boot.go#L100
And when the exec call fails, it's logged here:
https://github.com/apache/beam/blob/master/sdks/go/container/boot.go#L169
I'm not familiar with how the logging gets elevated to
errors/fatals/warnings etc from the container logs. The boot loaders don't use
anything particularly fancy for logging, just the standard library "log"
package, so it wouldn't hurt to upgrade it somewhat. I've already been
considering starting integration with the hopefully upcoming structured log
library for Go...
So that would be my suggestion: We switch the boot loaders to connect to the
FnAPI log service, and direct users to a beam site page where we can catalog
issues and solutions.
----
The bit that we don't have help for is relating the actual link error
easily. Redirecting the binary's StdErr might work, but could lead to other
noise going across the logging interface, or other duplication or overrun.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
