search

oxidecomputer / oxide.rs

The Oxide Rust SDK and CLI
Mozilla Public License 2.0
37 stars 12 forks source link

Single firewall rule add/remove #516

Open rmustacc opened 8 months ago

rmustacc commented 8 months ago

Target component

Overview

In the API, the firewall rules are an all or nothing payload. This is to allow for avoiding the dueling administrators problem and also to make it so if someone wants to transform the set of rules, they don't have to figure out a series of steps that leave things accidentally open (imagine adding an allow and deny rule in the wrong order).

However, as a human trying to consume this, this is a bit easy to screw up. Because you end up writing a replacement for the whole set on the CLI, you end up usually forgetting something and end up removing your allow-ssh rule or similar as an accidental side effect.

While we don't have conditional PUTs in the API yet, it'd be nice if there was a form that basically did the read/modify/write for you. That is, if we said add rule x, the CLI and/or SDK would do a GET, add it to the json blob, and then do a PUT (in the future with an etag).

Implementation details

No response

Anything else you would like to add?

I'm not sure if this should just be a think in the CLI or also an operation in the SDK.

labbott commented 8 months ago

A good example where I wanted this was when I was working on deploying via the SDK and needed to enable a port. I added that firewall rule but then lost my default ssh access. Fixing this via the CLI would be a good first step.

karencfv commented 8 months ago

I am wondering if instead of this feature, we want to have an additional set of APIs that does precisely this.

Not all of our users will be using the CLI 100% of the time, and we expect many(most?) will be writing their own tooling on top of the API. For example, a customer that chooses to generate their own SDK in a language we don't support yet would miss out on this feature.

ahl commented 8 months ago

That's a good question, @karencfv. The philosophy on the CLI has basically been as a thin wrapper on the API. If this would be useful for the CLI would it be useful for other API consumers?