Repository navigation
fix(compose): confine dynamic addresses to 10.10.10.128/26 - #972
Merged
Merged
Conversation
The network let Docker allocate dynamic addresses from the bottom of 10.10.10.0/24 while nostream, nostream-db and nostream-cache were pinned to .2-.4. otel-collector has no dependency that orders it after nostream, so it could be given .2 first and nostream then failed to start with "Address already in use" - most reliably after a host reboot, when the daemon starts containers in arbitrary order. An ip_range keeps the subnet and gateway as they were, so 10.10.10.1 remains the trusted proxy and the overlay pins (.5, .252, .253) stay outside the pool. A unit test holds every static address outside the dynamic pool in every compose file, so a future pin cannot silently land inside it. Closes #929
🦋 Changeset detectedLatest commit: 7ecf69c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
[Medium impact] The PR appears safe to merge.
|
Collaborator
Coverage Report for CI Build 40108860717Coverage increased (+0.006%) to 76.385%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats💛 - Coveralls |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was wrong
nostream,nostream-dbandnostream-cacheare pinned to10.10.10.2–.4, but the network let Docker allocate dynamic addresses from the bottom of the same10.10.10.0/24.otel-collectorhas no dependency that orders it afternostream, so it could be handed.2first and the relay then failed to start:Whichever container is created first wins the address, which makes this order-dependent and reliable after a host reboot.
The fix
An
ip_rangeon the default network confines dynamic allocation to10.10.10.128/26:The subnet and gateway are unchanged, so
10.10.10.1stays in the defaulttrustedProxies(resources/default-settings.yaml), and the overlay pins —.5(local),.252(i2p),.253(tor) — remain outside the pool. After the change the observability stack takes.128onward.Why a test rather than a comment
The failure mode returns the moment someone pins
.130.test/unit/ci/compose-network.spec.tsreads everydocker-compose*.yml, collects eachipv4_address, and asserts:ip_rangeis declared at all;Mutation-checked: removing
ip_rangefails two of the four; pinning10.10.10.130fails the fourth.Verification
Full unit suite: 2630 passing.
Not verified here: creating the network on a daemon. The development environment this was written in denies
docker network createby policy, so the end-to-end check isdocker network inspect nostreamshowingotel-collectorat.128or above — which is what the reporter saw in production with this exact config.Closes #929.