omdb assumes the default rack subnet

[jgallagher]

a4x2's default config is now passing a different rack_subnet to RSS, and #9501 (slated for R18) will expose this in wicket for new customer setups. However, omdb hardcodes our traditional default rack subnet, causing it to fail if the rack has anything else. From a4x2, failure by default due to the wrong DNS server address:

root@oxz_switch:~# omdb db sleds
note: database URL not specified.  Will search DNS.
note: (override with --db-url or OMDB_DB_URL)
note: using DNS server for subnet fd00:1122:3344::/48
note: (if this is not right, use --dns-server to specify an alternate DNS server)
Error: looking up Cockroach in DNS

Caused by:
    proto error: request timed out

but success if we pass the DNS server explicitly:

root@oxz_switch:~# omdb --dns-server [fd00:17:1:1::1]:53 db sleds
note: database URL not specified.  Will search DNS.
note: (override with --db-url or OMDB_DB_URL)
note: using database URL postgresql://root@[fd00:17:1:d02::4]:32221,[fd00:17:1:d02::3]:32221,[fd00:17:1:d01::3]:32221,[fd00:17:1:d01::4]:32221,[fd00:17:1:d03::3]:32221/omicron?sslmode=disable
note: database schema version matches expected (217.0.0)
note: listing all commissioned sleds (use -F to filter, e.g. -F in-service)
 SERIAL       IP                        ROLE      POLICY      STATE   ID
 00000000003  [fd00:17:1:d03::1]:12345  scrimlet  in service  active  0781a338-0544-4f4b-9c3a-ebec076d29e7
 00000000000  [fd00:17:1:d01::1]:12345  scrimlet  in service  active  ba25c03b-d1c5-412b-a04b-bb2c2adb2b10
 00000000001  [fd00:17:1:d02::1]:12345  -         in service  active  d8a2fe63-f0d5-4115-9060-92e4a9276414

We should probably fix this either as a part of or closely behind #9501, or omdb will be much more annoying to use in practice.

[davepacheco]

How do we fix this?

I expect this is hardcoded in a few other places, like maybe the live tests? (Sorry.)

[jgallagher]

sled-agent learns the rack subnet and passes it into the switch zone in various ways; could we either scrape one of the existing ones or add a new one specifically for omdb? Couple candidates for scraping: if the zone has an underlay interface (I think these are always named oxControlServiceN/omicron6); e.g.,

root@oxz_switch:~# ipadm | grep oxControlService
oxControlService46/ll addrconf ok       fe80::8:20ff:fe6f:dfa6%oxControlService46/10
oxControlService46/omicron6 static ok   fd00:17:1:d01::2/64

wicketd's SMF config has an explicit rack-subnet property:

    <instance name='default' enabled='true'>
      <property_group name='config' type='application'>
        <propval name='address' type='astring' value='[::1]:12226'/>
        <propval name='artifact-address' type='astring' value='[fdb0:a840:2500:1::2]:12227'/>
        <propval name='baseboard-file' type='astring' value='/opt/oxide/baseboard.json'/>
        <propval name='mgs-address' type='astring' value='[::1]:12225'/>
        <propval name='nexus-proxy-address' type='astring' value='[::]:12229'/>
        <propval name='rack-subnet' type='astring' value='fd00:17:1::'/>
      </property_group>
    </instance>

The interface won't exist and the property won't be filled in if the rack hasn't been set up yet, but omdb's not particularly useful then anyway. (I just mention that so we don't assume it's always there.)