Reject changes to system target release version if an update is in progress... #9188
Conversation
…ogress ... unless a mupdate has occurred, in which case we allow it. Fixes #8056.
|
This definitely needs some testing on a racklette before merging, but I believe implements what we decided to do for R17. |
| // * We don't keep the desired state of all Hubris components in the | ||
| // blueprint anyway. |
There was a problem hiding this comment.
Not for this PR, but is this something we should have? It feels a little dangerous to not have any kind of ongoing update check for the Hubris components. WDYT?
There was a problem hiding this comment.
We've talked about this a few times, and I think where we've landed is okay. We do have an ongoing update check for Hubris components, in that the planner is running periodically and will insert a PendingMgsUpdate for any component that doesn't match the current target release. Putting the intended state of all Hubris components in the blueprint is hard. A couple reasons (I'm sure there are more):
- A
PendingMgsUpdatehas a bunch of details other than the intended state, because we need all those details to perform updates safely - We need to avoid updating multiple components concurrently
mean it's not really clear how the execution side could act on intended state safely even if we had it.
Implicitly, the intended state for every Hubris component is "running whatever version is in the latest target release". We just have to take careful small steps to get there, which require a lot more involvement from the planner than higher-level components do.
2 participants
... unless a mupdate has occurred, in which case we allow it.
Fixes #8056.