-
Notifications
You must be signed in to change notification settings - Fork 43
[mgs] PendingMgsUpdate type to have a variant for the RoT #8054
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
[mgs] PendingMgsUpdate type to have a variant for the RoT #8054
Conversation
fn precheck<'a>( | ||
&'a self, | ||
_log: &'a slog::Logger, | ||
_mgs_clients: &'a mut MgsClients, | ||
_update: &'a PendingMgsUpdate, | ||
) -> BoxFuture<'a, Result<PrecheckStatus, PrecheckError>> { | ||
// TODO-K: fill in the precheck | ||
todo!() | ||
} | ||
|
||
/// Attempts once to perform any post-update actions (e.g., reset the | ||
/// device) | ||
fn post_update<'a>( | ||
&'a self, | ||
_log: &'a slog::Logger, | ||
_mgs_clients: &'a mut MgsClients, | ||
_update: &'a PendingMgsUpdate, | ||
) -> BoxFuture<'a, Result<(), GatewayClientError>> { | ||
// TODO-K: fill in the post_update | ||
todo!() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These will be completed in a follow up PR (step two of #7989)
@jgallagher, @lzrd adding either of you as reviewers since Dave will be out for a bit :) |
You are only covering RoT Hubris here, which is fine. I assume that RoT stage0 will be in later PRs. |
There should be some provision for ordering of updates. Stage0, then RoT Hubris, then SP Hubris. Also the restriction that only one RoT stage0 activation is in progress in the entire rack at a time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be some provision for ordering of updates. Stage0, then RoT Hubris, then SP Hubris. Also the restriction that only one RoT stage0 activation is in progress in the entire rack at a time.
These constraints will be in later PRs but do you need to carry any of the supporting information in these structures at this time? (probably not).
I think all of this is the responsibility of the planner; this work is about how to execute an update once the planner has decided it should happen.
Thanks for taking a look both! I think I've addressed all comments.
Yep! only RoT for now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Just a couple tiny renaming nits.
Implements the first step of updating the PendingMgsUpdate type to have a variant for the RoT. This lays out the foundation for the work in #7989