You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// TODO this should be ServiceName::Mgd, but in the upgrade
// path, that does not exist because RSS has not
// created it. So we just piggyback on Dendrite's SRV
// record.
As I understand the history here (which could definitely be wrong), at one point we changed RSS to make DNS records for this, but we couldn't rely on them because systems that were set up by RSS prior to that change (like dogfood) wouldn't have them.
Fortunately, Reconfigurator can now ensure that DNS records are consistently created for all systems.
If the DnsConfigBuilder already has the information it needs to create the correct records, then I think you can just change it to do so and that will cause RSS to generate the records and the records will be generated on existing systems the next time somebody executes a blueprint. I think @jgallagher confirmed this while working on #6050. If you need to change the DnsConfigBuilder interface, it still shouldn't be too bad. I think it only has two consumers: RSS and this function:
// This unwrap is safe because this function only fails if we provide
// the same zone id twice, which should not be possible here.
dns_builder
.host_zone_with_one_backend(
zone.id,
zone.underlay_address,
service_name,
port,
)
.unwrap();
}
let scrimlets = sleds_by_id.values().filter(|sled| sled.is_scrimlet);
for scrimlet in scrimlets {
let sled_subnet = scrimlet.subnet();
let switch_zone_ip = overrides.switch_zone_ip(scrimlet.id, sled_subnet);
// unwrap(): see above.
dns_builder
.host_zone_switch(
scrimlet.id,
switch_zone_ip,
overrides.dendrite_port(scrimlet.id),
overrides.mgs_port(scrimlet.id),
overrides.mgd_port(scrimlet.id),
)
.unwrap();
}
dns_builder.build_zone()
}
We still have to make sure that a blueprint does get executed on customer systems, and it may take two releases before we can rely on these being present (i.e., deploy the release that creates the records and execute a blueprint; then deploy another release that relies on the records). But there's definitely a path at this point to getting new DNS records installed.
The reason this is important is that without this, the code has to hardcode the port number to use, which I'm guessing is part of the reason for #6076. Might this also help with #5092?
From this TODO:
omicron/nexus/src/app/mod.rs
Lines 325 to 328 in e4bcfee
As I understand the history here (which could definitely be wrong), at one point we changed RSS to make DNS records for this, but we couldn't rely on them because systems that were set up by RSS prior to that change (like dogfood) wouldn't have them.
Fortunately, Reconfigurator can now ensure that DNS records are consistently created for all systems.
If the
DnsConfigBuilder
already has the information it needs to create the correct records, then I think you can just change it to do so and that will cause RSS to generate the records and the records will be generated on existing systems the next time somebody executes a blueprint. I think @jgallagher confirmed this while working on #6050. If you need to change theDnsConfigBuilder
interface, it still shouldn't be too bad. I think it only has two consumers: RSS and this function:omicron/nexus/reconfigurator/execution/src/dns.rs
Lines 248 to 332 in e4bcfee
We still have to make sure that a blueprint does get executed on customer systems, and it may take two releases before we can rely on these being present (i.e., deploy the release that creates the records and execute a blueprint; then deploy another release that relies on the records). But there's definitely a path at this point to getting new DNS records installed.
The reason this is important is that without this, the code has to hardcode the port number to use, which I'm guessing is part of the reason for #6076. Might this also help with #5092?
CC @internet-diglett
The text was updated successfully, but these errors were encountered: