Use networking patch in docker too
Closed this issue · 4 comments
We should use the same josie-patched version of Core in both docker and k8s:
Advantages:
- single image / registry
- single image building pipeline
- can be built with guix:
- smaller image sizes
- no libs needed
- improved performance (lower ram usage)
Disadvantages:
- no downsides?
- prevents a "firewalled" setup (one node with a single LAN connection to a "firewall" public-facing node, add unsupported feature to docs?
A couple of disadvantages:
- modifying what's under test, however small, from a production release means you aren't testing the same artefact
- it's another step away from users being able to run their own bitcoind images as they will need warnet modifications to run
My ideal is that warnet accommodates for off-the-shelf bitcoind images.
modifying what's under test, however small, from a production release means you aren't testing the same artefact
But here I think it's so insignificant as not to matter? We just mention that warnet does not distinguish between routable and unroutable connection types and, thats it!?
it's another step away from users being able to run their own bitcoind images as they will need warnet modifications to run
We could actually still accommodate this, i think, by using a custom patch loaded by LD_PRELOAD. IIUC you can override any function call by launching the binary with LD_PRELOAD and we could apply the patch in this way?
LD_PRELOAD would be a neat trick if it works.
Regarding how significant the change is, I agree and my intuition says the same. That said, unintended consequences have been known to happen from time to time. I see it as an ideal to have things as close as possible but obviously with testing compromises are always made to make it practical.
We are now unsure whether the patch is working properly in k8s. Would be good to have clarification on that.