-
Notifications
You must be signed in to change notification settings - Fork 19
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 explicit Stopping state (2/3) #1570
base: mkeeter/simplify-faults
Are you sure you want to change the base?
Conversation
e31a3ad
to
0282d48
Compare
3366d4b
to
9973b28
Compare
8f67994
to
3d11ac2
Compare
3d11ac2
to
de39d6e
Compare
9973b28
to
16a680c
Compare
de39d6e
to
26823a9
Compare
18d86f5
to
26061a7
Compare
26061a7
to
05e8ba6
Compare
The Here is a diff to fix it. I can also just push this to your branch directly (I thinik..)
|
upstairs/src/client.rs
Outdated
// XXX there are some `Stopping` cases which should never happen, | ||
// should we panic on them (like we do for negotiation states | ||
// below)? |
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.
I'd say yes but I think that should be addressed in the next PR in the series (?)
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.
I tried both ways, but because it's just affecting DsState::Stopping(..)
, it seems reasonable to do here.
DsState::Faulted | | ||
// It's also possible for a Downstairs to be in the process of | ||
// stopping, due a fault or disconnection | ||
DsState::Stopping(..) // XXX should we be more specific here? |
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.
maybe?
also, slight nit: I think we should do away with this assert, move the comments to the match on client state below, and panic on the catch-all case. We're missing both Faulted and Stopping(..) enum variants in the below match, and I'd rather be explicit there that we don't have to do anything in those cases.
@leftwo I applied your patch, thanks! |
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.
Some simple questions for you
upstairs/src/client.rs
Outdated
| DsState::LiveRepairReady => EnqueueResult::Skip, | ||
| DsState::LiveRepairReady | ||
| DsState::Stopping(..) => EnqueueResult::Skip, | ||
// XXX there are some `Stopping` cases which should never happen, |
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.
I vote yes for panic. If we really think they should never happen, and we silently allow them through, what would that mean? Could we allow an IO to go out that should not?
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.
The panics here are last-chance invariant maintenance. I've split up DsState::Stopping
into multiple different substates in 3eb259f ; opinions are welcome as to which should panic versus skipping the IOs (the only obvious one is Deactivated
, which should not send further IO).
DsState::Deactivated => "DAV".to_string(), | ||
DsState::Disabled => "DIS".to_string(), | ||
DsState::Replacing => "RPC".to_string(), | ||
DsState::Stopping(ClientStopReason::Deactivated) => "DAV".to_string(), |
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.
I just noticed, this DsState
change does impact how the dtrace scripts (in tools/dtrace) output looks when we print the generic state. When the final PR from this group lands we will have to update the DTrace scripts so columns align.
DsState::Faulted | | ||
// It's also possible for a Downstairs to be in the process of | ||
// stopping, due a fault or disconnection | ||
DsState::Stopping(..) // XXX should we be more specific here? |
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.
Would ClientStopReason::NegotiationFailed
be valid here? That would be the only one I might not expect to see.
Looking at 3/3 in this series, some of the questions/comments here might be obsolete with what happens in 3/3. |
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.
I think I just have one question left.
Staged on top of #1568
There's an unfortunate ambiguity in certain states (e.g.
DsState::Faulted
), which represent two different things:This PR adds a new
DsState::Stopping(ClientStopReason)
state, which represents the former. The previous states (DsState::Faulted
) now only mean that we're doing negotiation.The new state subsumes
DsState::Deactivated
,DsState::Replacing
,DsState::Disabled
, which were specialized states that waited for the IO task to exit. Each of those states is nowDsState::Stopping(..)
with an appropriateClientStopReason
.The vast majority of this PR is automatic OpenAPI changes. I don't think anyone is relying on the specific shape of
DsState
(which is only used inUpstairsInfo
/ theinfo
endpoint), but please let me know if I'm wrong!