VPC routing: Want CLI command to reset a system router

[FelixMcFelix]

Target component

• [X] CLI
• [ ] SDK
• [ ] Something else
• [ ] Not sure

Overview

Since the outbound/default routes in a VPC system router have mutable targets, it's possible for a user to shut themselves off from being able to SSH into their instances. While fixing this state is easy enough (and outlined in the guide), a command to reset these routes to their factory default would save some time.

Implementation details

The system router and its routes have fixed names in a VPC. We can probably then have:

oxide vpc router restore-default [v4, v6, *both*] \
  --project oxdoc \
  --vpc subnet-guide

Anything else you would like to add?

No response

[ahl]

The CLI is mostly a wrapper around the API. Do we want an API that corresponds to this action? Or why would we prefer this as a custom CLI-only action?

[david-crespo]

In other words, what would this look like with existing commands, and can we tolerate putting that command in a doc and saying "run this"?

[ahl]

I was thinking more "if this is useful, let's make it an API call rather than implement the logic in the CLI and console"

[david-crespo]

Depends on how ugly the existing command is! If it takes an arbitrary number of commands because it scales with the number of routes, then definitely would like this in the API instead.

[FelixMcFelix]

With existing commands, for IPv4 it looks like (in the forthcoming guide):

restore.json

{
  "destination": {"type": "ip_net", "value": "0.0.0.0/0"},
  "target": {"type": "internet_gateway", "value": "outbound"}
}

oxide vpc router route update \
  --project oxdoc \
  --vpc subnet-guide \
  --router system \
  --route default-v4 \
  --json-body restore.json

(The destination value must be updated if we also need to restore the v6 route. There are only two default routes in total in the system router, nothing else there is user-modifiable.)

I would say the original thought process here was that this requires a bit more effort on the CLI (due to --json-body) than it would via the SDK or API. I can see the value in just making it into an endpoint, however since we'd be forcing those consumers to jump through the same hoops (correct names, correct destination, knowledge that InternetGateway("outbound") is the default).