Bump dependencies, progenitor to a69e18c8, oxide.json to omicron:882de613

[oxide-reflector-bot]

Lock file updated

Bump progenitor from 2f9b6c93 to a69e18c8
Changes: oxidecomputer/progenitor@2f9b6c9...a69e18c

Generated code against nexus-2026020901.0.0-2a09a7.json 882de613

CLI docs updated against the updated CLI

[david-crespo]

Looks good!

We chatted about whether oxide system networking ip-pool create was kind of heavy (it is) and whether there's a different grouping of commands we could use to avoid it (there isn't). networking is a natural grouping and it's the least bad option vs. putting all the networking stuff directly under oxide system or splitting networking between Important Ones (under system ) and Little Weird Ones (under system networking).

Alternative system networking command groupings

Status quo

system
├── hardware (5 subgroups, ~18 ops)
├── networking
│   ├── addr (2 ops)
│   ├── address-lot (5 ops)
│   ├── allow-list (2 ops)
│   ├── bfd (3 ops)
│   ├── bgp (17 ops)
│   ├── inbound-icmp (2 ops)
│   ├── ip-pool (11 ops)
│   ├── link (2 ops)
│   ├── lldp (3 ops)
│   ├── loopback-address (3 ops)
│   ├── route (2 ops)
│   ├── subnet-pool (12 ops)
│   └── switch-port-settings (5 ops)
├── policy (2 ops)
└── update (4 subgroups, ~8 ops)

4 items under system, but networking is 13 subcommands / 69 ops doing all the work.

Natural groupings within networking

The 13 subcommands break into clusters:

Pool management (resource allocation): ip-pool, subnet-pool
Routing protocols: bgp, bfd
Switch port config: addr, link, switch-port-settings, lldp, route, address-lot, loopback-address
API service access: allow-list, inbound-icmp

The pain is worst for the pools and bgp — those are the things people actually type most, and system networking ip-pool create is 4 words deep. The switch port config stuff is inherently obscure and nesting it is fine.

Option A: Keep networking (slimmed)

Pull ip-pool, subnet-pool, bgp, and bfd up to direct children of system. Leave the switch fabric config under networking.

system
├── bgp (17 ops)
├── bfd (3 ops)
├── hardware (5 subgroups, ~18 ops)
├── ip-pool (11 ops)
├── networking
│   ├── addr (2 ops)
│   ├── address-lot (5 ops)
│   ├── allow-list (2 ops)
│   ├── inbound-icmp (2 ops)
│   ├── link (2 ops)
│   ├── lldp (3 ops)
│   ├── loopback-address (3 ops)
│   ├── route (2 ops)
│   └── switch-port-settings (5 ops)
├── policy (2 ops)
├── subnet-pool (12 ops)
└── update (4 subgroups, ~8 ops)

8 items under system. networking is 9 subcommands / 26 ops of switch fabric stuff. Downside: networking now means "networking, other than the obvious networking things we promoted to top level."

Option B: No networking, flatten everything

system
├── address-lot (5 ops)
├── allow-list (2 ops)
├── bfd (3 ops)
├── bgp (17 ops)
├── hardware (5 subgroups, ~18 ops)
├── inbound-icmp (2 ops)
├── ip-pool (11 ops)
├── link (2 ops)
├── lldp (3 ops)
├── loopback-address (3 ops)
├── policy (2 ops)
├── port-addr (2 ops)
├── route (2 ops)
├── subnet-pool (12 ops)
├── switch-port-settings (5 ops)
└── update (4 subgroups, ~8 ops)

16 items under system. No intermediate grouping. The small 2-op commands (addr, link, route, allow-list, inbound-icmp) feel a bit exposed at this level, but nothing is deeply buried. system --help becomes a wall.