BlueprintBuilder: require caller to provide internal DNS subnet #9250
+69
−241
Conversation
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
This is part of #9238: we'd like to pull `BlueprintResourceAllocator`'s weird construction out of `BlueprintBuilder`, and this removes _one_ use of it. When adding an internal DNS zone, the caller must now specify the `DnsSubet` instead of `BlueprintBuilder` choosing internally. To assist with this, adds `BlueprintBuilder::available_internal_dns_subnets()`, which returns an iterator of available subnets. I'm not sure this is the right interface; will leave a comment inline with some other ideas.
jgallagher
commented
Oct 17, 2025
| .map(|(_sled_id, resources)| resources.subnet) | ||
| .next() | ||
| .ok_or(Error::RackSubnetUnknownNoSleds)?; | ||
| let rack_subnet = ReservedRackSubnet::from_subnet(any_sled_subnet); |
There was a problem hiding this comment.
This is the part I like the least. Some alternatives I considered:
- Instead of
available_internal_dns_subnets(), provideinternal_dns_subnets_in_use(), and require the caller to do this work and the filtering we do based on it below. This seems the most true to a "dumb builder" pattern, but puts some annoying work on every caller. - Instead of returning an error on line 713, return an empty iterator if we don't have any commissioned sleds.
- A mix of 1 and 2: instead of returning a raw iterator, return an
AvailableInternalDnsSubnetstype that is more like theInternalDnsSubnetAllocatorremoved in this PR: internally it only tracks the "in use" subnets, and requires the caller to pass in a sled subnet (from which we can derive a rack subnet and the set of possible DNS subnets).
Do any of these seem more likely to put us in a better position w.r.t. multirack? (How will internal DNS subnets be configured in multirack?)
There was a problem hiding this comment.
The approach you've got here seems fine to me for now!
davepacheco
approved these changes
Oct 28, 2025
| .map(|(_sled_id, resources)| resources.subnet) | ||
| .next() | ||
| .ok_or(Error::RackSubnetUnknownNoSleds)?; | ||
| let rack_subnet = ReservedRackSubnet::from_subnet(any_sled_subnet); |
There was a problem hiding this comment.
The approach you've got here seems fine to me for now!
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.
This is part of #9238: we'd like to pull
BlueprintResourceAllocator's weird construction out ofBlueprintBuilder, and this removes one use of it. When adding an internal DNS zone, the caller must now specify theDnsSubetinstead ofBlueprintBuilderchoosing internally.To assist with this, adds
BlueprintBuilder::available_internal_dns_subnets(), which returns an iterator of available subnets. I'm not sure this is the right interface; will leave a comment inline with some other ideas.