oxidecomputer / oxidecomputer/omicron

want external API client in live tests

Open
#7,968 0 comments 0 reactions 1 assignee View on GitHub

@hawkw is already working on this.

Since Apr 13, 2025.

Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Description

Presently, the LiveTestContext provided to live tests has a way to get a Nexus internal API client, but has no way to construct an external API client. This would be nice to have, as the live test system would be useful for testing operations initiated through the external API. Of course, in some cases, a live test could just use its datastore client to perform the same CRUD operations as the external API, but some API endpoints do more than just database CRUD queries --- they may start sagas, activate background tasks, or make requests to sled-agents, for instance. And, reimplementing an endpoint in the live test creates opportunities for drift between the test and what the endpoint actually does, even if that endpoint is just doing DB CRUD stuff.

Of course, this is is complicated a bit because the live tests run in the switch zone, so they are not, in fact, "external" to the rack. I was thinking that this could potentially be implemented using the technician port external API server. Since this is served on the same IP as the internal API, the live test could just look up a Nexus' internal API address and change the port. But, it's possible there's some reason that wouldn't work that I'm overlooking. It also would probably be necessary to ensure that the live test environment has a user that the live test can log in as --- the rkadm scripts for installing the control plane on racklettes create the recovery user with a hard-coded username and password, but I'm not sure whether this is also true for a4x2?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.