Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add pending MGS-managed updates to blueprint #7741

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

davepacheco
Copy link
Collaborator

@davepacheco davepacheco commented Mar 5, 2025

Like we did with zone images, this PR only contains updates to the in-memory representation. Database support and reconfigurator-cli support will come in a follow-on PR.

This is theoretically ready to go, but there's no rush yet as there's no consumer yet.

@davepacheco davepacheco marked this pull request as ready for review March 6, 2025 01:14
@davepacheco
Copy link
Collaborator Author

This PR reflects a work-in-progress that Jordan and I are doing separate work based off. This isn't set in stone yet but I wanted to document the plan here.

The idea is that the blueprint maintains a list of pending MGS-managed updates. An MGS-managed update is any update done by the SP and controlled via MGS, which means: RoT bootloader, RoT Hubris image, SP Hubris image, and host phase 1. There may be at most one of these pending for any baseboard at once, but there could be multiple baseboards getting an update at once. (A baseboard is a thing with an SP on it: Gimlet, Sidecar, or PSC.)

When the planner wants to update one of these things, it adds a PendingMgsUpdate to the (next) blueprint. When it notices that the inventory reflects that that change has been made, it removes it from the (next) blueprint.

I was initially reluctant about this approach because it sounds a little like "storing the steps", which we've explicitly avoided elsewhere with blueprints. It's not really, though, because it's not saying "you should perform this update next". It's saying what should be deployed -- just limiting what it's specifying to only the sleds it wants to take action on. (If we just stored the end state (the desired version of each thing), then during execution, we'd have to query everything in the system for its current version and check it against what the blueprint said we should have. That's duplicating all the work the planner literally just did. Further, that might cause us to do something different than the planner expected (what if when the planner made its decision, it was intending to update one sled; but now some other sled is also behind, and now we wind up resetting a sled unexpectedly -- yikes).)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants