search

oxidecomputer / omicron

Omicron: Oxide control plane
Mozilla Public License 2.0
220 stars 33 forks source link

Add interfaces to make wicket usable in an automated testing environment #3928

Open jgallagher opened 10 months ago

jgallagher commented 10 months ago

wicket currently exposes functionality in two ways: the main wicket TUI (most functionality, including triggering rack setup), and clap-driven CLI subcommands (mostly anything that provides input, particularly the configuration for rack setup). When we get to the point where we want to run tests on real hardware lab environments, we will want to drive wicket in an automated way. A couple obvious options are:

  1. Invest in testing and driving the wicket TUI (multiple implementation options are available here; e.g., something like expect that reads and navigates the TUI as-is, hooking into the event / replay stream a la the wicket debugger)
  2. Expose more functionality in the CLI, since it should be straightforward to drive those automatically

IMHO 2 would be relatively quick and easy, but 1 might be more valuable (since it would give us more extensive testing of wicket itself).

sunshowers commented 10 months ago

I started working on a wicket rack-update command.

Questions:

  1. It seems like a single wicket command should be able to kick off multiple updates across sleds, switches and PSCs. Is that true?
  2. It also seems like in the update command we should be able to resume showing statuses if wicket gets disconnected, similar to how the tui works. Does that make sense?
  3. Given that the primary use case is CI, how do we want to present statuses? Since we can't really show progress bars in CI, I was thinking just a flat list of e.g. [sled 14] Started step: Downloading installinator etc. Does that make sense?
jgallagher commented 10 months ago
  1. It seems like a single wicket command should be able to kick off multiple updates across sleds, switches and PSCs. Is that true?

I think so. I could see an argument for "wicket presents single-sled commands and something higher level (maybe an xtask) is responsible for running multiple updates concurrently", but it does seem more convenient to provide it at the wicket level.

  1. It also seems like in the update command we should be able to resume showing statuses if wicket gets disconnected, similar to how the tui works. Does that make sense?

Yeah, definitely. preflight uplink-status has this in case someone hits ctrl-c while the uplink check is running; it just resumes polling for completion without starting the check first.

  1. Given that the primary use case is CI, how do we want to present statuses? Since we can't really show progress bars in CI, I was thinking just a flat list of e.g. [sled 14] Started step: Downloading installinator etc. Does that make sense?

Yep, makes sense to me.