[28/n] [wicketd] add the commission API, client, and OpenAPI document#10857
Conversation
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
…ch (#10888) Found while reviewing #10857. Currently, for transceivers: 1. There's a single `last_seen` across both switches. 2. The `last_seen` is snapshotted at update time, which means that it would only measure how long the update was in the mpsc channel for. Both of these seem incorrect, and in particular the second one would show up as wicket always reporting <1s. <img width="1584" height="332" alt="image" src="https://github.com/user-attachments/assets/c203a9f6-5760-4ec0-a146-e33e550a048a" /> Fix both these issues. To maintain the same wire shape, for point 1 we pick `max`. (The commissioning API will publish per-switch last seen values.) For point 2 there will be a behavior change visible in wicket, but that seems correct.
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
andrewjstone
left a comment
There was a problem hiding this comment.
@sunshowers this looks great so far. I did a preliminary review. I mostly skipped conversions.rs and I still need to look at the integration tests and the http handler and progress files.
| /// Report the update progress of every service processor with update state | ||
| #[endpoint { | ||
| method = GET, | ||
| path = "/update-progress", |
There was a problem hiding this comment.
Why not /update-progress/sps ? Don't we update other things and show progress?
There was a problem hiding this comment.
I should be clear, that I was trying to match this path with the comment.
| HttpError, | ||
| >; | ||
|
|
||
| /// Start updating one or more service processors |
There was a problem hiding this comment.
Same as above. I find it somewhat weird that /update only applies to sps.
There was a problem hiding this comment.
It's actually doing a full MUPdate -- the nomenclature around SP is a bit of an implementation detail that's leaking here.
There was a problem hiding this comment.
What should this be, though? "sleds" is too narrow because this is how you update switches and PSCs as well. "component" feels like a very overloaded term
| /// Reported so that "a peer is on the bootstrap network but cannot be | ||
| /// matched to inventory" is distinguishable from "the sled has not been | ||
| /// discovered on the bootstrap network yet" (a `None` `BootstrapSled::ip`). | ||
| pub unmatched_peers: Vec<UnmatchedBootstrapPeer>, |
There was a problem hiding this comment.
I really like that you added this field. Thanks!
| /// The current status of any rack-level operation being performed. | ||
| #[derive(Clone, Debug, Serialize, Deserialize, JsonSchema, PartialEq, Eq)] | ||
| #[serde(tag = "status", rename_all = "snake_case")] | ||
| pub enum RackOperationStatus { |
There was a problem hiding this comment.
My PR adding the multirack join service actually changed this status. It's unfortunate, but there needed to be a way to show that multirack was precluding the operation of RSS or vice versa. I suppose for this API, we can do some type of conversion. I was just finding it hard to completely isolate the two, since we need to prevent them from running simultaneously.
There was a problem hiding this comment.
Ah interesting. To be honest RSS should use the update engine! Then it can use the progress types which do not bake that kind of knowledge in.
There was a problem hiding this comment.
Oh what I'm now wondering is if I can translate RSS information to the progress types.
| // TODO: once rkdeploy is on the published API, we can make | ||
| // `event_reports` be an IdOrdMap and make this much simpler. | ||
| let mut entries = IdOrdMap::new(); | ||
| for (sp_type, slots) in event_reports { |
There was a problem hiding this comment.
Hey @sion42x, look Rain used a nested loop too!
There was a problem hiding this comment.
Yeah, sorry for not building iddqd back in 2023 ;)
Created using spr 1.3.6-beta.1
This change implements v1 of the wicketd commission API, as described in RFD 710.
This is a pretty large change, so here's a short orientation and review guide.
What this PR is not
Review guide
The API surface matches what rkdeploy needs almost 1:1. I've paid attention to the type design and ensuring that any partial errors are properly reported to clients (something that was a bit lacking in the unstable API).
I would spend the most time looking at:
wicketd/src/commission/conversions.rs-- in particular, with extensive use of destructuring.Part of the review is going to be integrating with rkdeploy -- @JustinAzoff is taking care of this.
Note that while this API is server-side versioned, changing it does carry a substantial cost because such a change has to be coordinated with rkdeploy. So it's worth getting it right.
Depends on:
TODO: