bitcoin-dev-project / bitcoin-dev-project/warnet

Re-add ASmap support (followup to #146 / #217)

Open
#807 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
149
Forks
83
Avg merge
4d 8h
Merged PRs (30d)
2

Description

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

1. Does A or B (or some other shape) match how warnet should evolve?
2. 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.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.