Quick motivation: I'd like to experiment a bit with -asmap effectiveness and netgroup-bucketing on a realistic topology and warnet seems like the natural substrate, but -asmap= isn't currently reachable through the chart.
Picking back up the ASmap question that willcl-ark parked in #217 with "we can revisit if needed." With ASmap now embedded in Bitcoin Core v31.0 it's worth another look at warnet, and I'd appreciate input on the right architectural shape before any PR.
What's actually disabled today
resources/images/bitcoin/addrman.patch is applied unconditionally in both Dockerfiles. It extends the netgroup vector with the lower two IPv4 bytes, turning bucketing from /16 into /32. Because both the default /16 path and any ASmap path share GetGroup(), the patch silently disables both. So even leaving ASmap aside, scenarios that reason about peer diversity at the netgroup level aren't exercising the production codepath.
On top of that, the bitcoincore chart has no -asmap= plumbing and no mount slot for an asmap file.
Two plausible shapes
I'd rather decide direction before writing code:
A) postNetwork plugin that reads per-tank ASN annotations from network.yaml, builds a synthetic asmap from scheduled pod IPs, and exposes it as a ConfigMap. Tanks gate on it via an init-container. The same pattern already used for loadSnapshot.enabled in pod.yaml. Closest to m3dwards' #217 sketch, adapted to the current architecture.
B) Minimal -asmap= plumbing only in the chart, with users supplying their own asmap. Pod IPs stay unmapped (fall back to /16 bucketing for them), but it's a small, single-PR change that covers use cases where pod-IP-to-ASN mapping isn't the point.
Both share a prerequisite: making addrman.patch conditional via build-arg, since nothing downstream of GetGroup() matters until that's lifted.
What I'm asking
- Does A or B (or some other shape) match how warnet should evolve?
- Is the conditional
addrman.patch worth a separate small PR first? It independently unblocks any netgroup-aware testing, ASmap or not.
Happy to drop this if there's no appetite right now. Wanted to surface the design question before investing implementation time.
Quick motivation: I'd like to experiment a bit with -asmap effectiveness and netgroup-bucketing on a realistic topology and warnet seems like the natural substrate, but -asmap= isn't currently reachable through the chart.
Picking back up the ASmap question that willcl-ark parked in #217 with "we can revisit if needed." With ASmap now embedded in Bitcoin Core v31.0 it's worth another look at warnet, and I'd appreciate input on the right architectural shape before any PR.
What's actually disabled today
resources/images/bitcoin/addrman.patchis applied unconditionally in both Dockerfiles. It extends the netgroup vector with the lower two IPv4 bytes, turning bucketing from /16 into /32. Because both the default /16 path and any ASmap path shareGetGroup(), the patch silently disables both. So even leaving ASmap aside, scenarios that reason about peer diversity at the netgroup level aren't exercising the production codepath.On top of that, the bitcoincore chart has no
-asmap=plumbing and no mount slot for an asmap file.Two plausible shapes
I'd rather decide direction before writing code:
A)
postNetworkplugin that reads per-tank ASN annotations from network.yaml, builds a synthetic asmap from scheduled pod IPs, and exposes it as a ConfigMap. Tanks gate on it via an init-container. The same pattern already used forloadSnapshot.enabledin pod.yaml. Closest to m3dwards' #217 sketch, adapted to the current architecture.B) Minimal
-asmap=plumbing only in the chart, with users supplying their own asmap. Pod IPs stay unmapped (fall back to /16 bucketing for them), but it's a small, single-PR change that covers use cases where pod-IP-to-ASN mapping isn't the point.Both share a prerequisite: making
addrman.patchconditional via build-arg, since nothing downstream ofGetGroup()matters until that's lifted.What I'm asking
addrman.patchworth a separate small PR first? It independently unblocks any netgroup-aware testing, ASmap or not.Happy to drop this if there's no appetite right now. Wanted to surface the design question before investing implementation time.