Skip to content

Conversation

jgallagher
Copy link
Contributor

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.

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.
.map(|(_sled_id, resources)| resources.subnet)
.next()
.ok_or(Error::RackSubnetUnknownNoSleds)?;
let rack_subnet = ReservedRackSubnet::from_subnet(any_sled_subnet);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the part I like the least. Some alternatives I considered:

  1. Instead of available_internal_dns_subnets(), provide internal_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.
  2. Instead of returning an error on line 713, return an empty iterator if we don't have any commissioned sleds.
  3. A mix of 1 and 2: instead of returning a raw iterator, return an AvailableInternalDnsSubnets type that is more like the InternalDnsSubnetAllocator removed 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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant