-
Notifications
You must be signed in to change notification settings - Fork 1.6k
cli: introduce host-perf-check command #4342
Conversation
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.
A few nits, generally looks like you're on a good path.
- Improve error handling - Keep subcommands available in both debug and release builds
We do 2 *nix things here: get cargo run --release host-perf-check multiple times to verify it's cached. Can only confirm it for Linux myself unfortunately. |
@drahnr so we are fine with the rest? I will add erasure code test and optional run on the first launch then before marking it as ready-for-review. |
I am rather uneasy about all the deps pulled in, either we use something more abstract, i.e. |
|
We have the |
There're no constant multipliers yet, we will probably soften the limit with respect to reference values -- tbd. |
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.
👍
{ | ||
Err(PerfCheckError::WrongBuildType.into()) | ||
} | ||
#[cfg(build_type = "release")] |
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.
will this work with custom profiles #4311 (comment) @bkchr?
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 don't think so, the profile should be matched with the one used for distributing the binary. If this profile changes to e.g release-lto
, it should be also updated 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.
While we don't officially support windows, I think that we at least compiled on windows all the time.
I get why you want to store the host name there, but it still feels weird.
I mean users could already run into more trouble when the just blindly copy the entire base path, because they could be slashed for equivocations etc. Especially as the check is currently optional anyway? Aka needs to be executed by the user.
I suppose it is already broken in
This is a minor effort we can afford in order to protect users from it isn't it? |
Okay, good point :)
Is that already done? No or? |
Not yet, I'm unsure about the way of implementing it, it should always be optional so:
cc @drahnr |
Given that we don't want any potential issues with node restarts, on-by-default is not an option. Online host migrations pose also an issue, when the username changes, or the hostname is changed and on next restart it experiences the delay. That's all not good UI, and I'd prefer to ship the partial feature, having just the explicit command and post pone the rest. |
But then we don't need any of this caching feature? If this is something that stays optional and requires the user to run the command, why cache it? |
Fully agree, deferring the caching and the resolution seems to me like the best approach. @slumber could remove the file related caching values, the rest is good to go! |
bot merge |
Error: Checks failed for 66dfa6d |
Resolves #4196
Creating as a draft since there're couple of unresolved questions so the code needs to be polished.
But the general approach is here so we have a starting point.