Jorik Jonker

Having the same issue, without `GODEBUG` flag. These are my resource settings: ```yaml requests: cpu: 50m memory: 256Mi limits: cpu: 1 memory: 1Gi ``` Have raised the limit to 2G...

I'm a bit divided on wether or not this default makes sense. On the one hand I think in a typical situation, Zipkin needs to be outside of the mesh...

I've created a PR to include extra environment variables, should to the trick.

FWIW, I build (local) multiarch (arm64/amd64) docker images of NFS using this commandline: ``` $ git checkout v0.9.0 $ make IMAGE_BUILD_CMD="docker buildx build --push --platform linux/amd64,linux/arm64" IMAGE_REGISTRY="docker.io/jonkerj" ``` Should not...

It could be a feature/limitation of your docker environment or buildx initialization, above invocation works for me (docker 20.10.8 / buildx v0.6.1 / moby/buildkit:buildx-stable-1)

The [Raspbernetes project](https://github.com/raspbernetes/multi-arch-images) automatically builds multi-arch images of several projects, including NFD. You could take a look at [the workflow file](https://github.com/raspbernetes/multi-arch-images/blob/master/.github/workflows/node-feature-discovery.yml), which essentially wraps `docker buildx build`

Hi guys, any movement in this matter?

Just a little message to let you guys know I am still meaning to restart my efforts to fix/clean up the CD, include ARM64 and fix armv6 soon :-)

Some news: I've restarted my efforts to clean-up the CD and adding arm64/aarch64 to it. I'm going to leverage debian's multiarch, so you can do stuff like this: ``` dpkg...

I took me a while to get working too. Turned out that when you do not have the exact same package versions for native and cross things explode. For example,...