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

[Cli] Add default_prompt_response option to set_global_config command #5614

Merged
merged 9 commits into from
Dec 6, 2022
Merged

[Cli] Add default_prompt_response option to set_global_config command #5614

merged 9 commits into from
Dec 6, 2022

Conversation

fgrust
Copy link
Contributor

@fgrust fgrust commented Nov 17, 2022

[WIP]

Description

Updates for issue #2205

Test Plan

This PR is in WIP, so far saving the configuration in the config file works well.

$ aptos config set-global-config --default-prompt_response yes
$ aptos config show-global-config
{
  "Result": {
    "config_type": "Global",
    "default_prompt_response": "Yes"
  }
}

This change is Reviewable

Copy link
Contributor

@gregnazario gregnazario left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey this is a great first start!

I think you'll want to do one of these two options:

  1. Make an enum with, [yes, no, prompt], where prompt is default
  2. Take advantage of Option<bool>, to handle None as prompt.

It's probably easier from a readability perspective for the first one, and then it can default to prompt.

Then you can loop this into the PromptOptions to read the global config and use this as the default behavior rather than what it does right now

@banool
Copy link
Contributor

banool commented Nov 17, 2022

Agree with Greg, particularly with the first thing he suggests.

@fgrust
Copy link
Contributor Author

fgrust commented Nov 18, 2022

Hey this is a great first start!

I think you'll want to do one of these two options:

  1. Make an enum with, [yes, no, prompt], where prompt is default
  2. Take advantage of Option<bool>, to handle None as prompt.

It's probably easier from a readability perspective for the first one, and then it can default to prompt.

Then you can loop this into the PromptOptions to read the global config and use this as the default behavior rather than what it does right now

I also agree with the first thing.

Please review the updated code, and then I will move forward with PromptOptions as the config logic is approved.

@fgrust fgrust requested review from gregnazario and removed request for banool November 18, 2022 17:30
@banool
Copy link
Contributor

banool commented Nov 18, 2022

Will look next week :)

@@ -174,6 +184,9 @@ pub struct GlobalConfig {
/// Whether to be using Global or Workspace mode
#[serde(skip_serializing_if = "Option::is_none")]
pub config_type: Option<ConfigType>,
/// Prompt response type
#[serde(skip_serializing_if = "Option::is_none")]
pub default_prompt_response: Option<PromptResponseType>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use serde(default) here instead of making this an Option? As it is now the Option doesn't really make much sense given there is also a Prompt variant of the PromptReponseType enum.

Copy link
Contributor Author

@fgrust fgrust Nov 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, it would save default_prompt_response: Prompt in the config file, even if we run set-global-config without --default-prompt-response option. It's what we should come up with?

ASSUME_YES => Ok(Self::Yes),
ASSUME_NO => Ok(Self::No),
_ => Err(CliError::CommandArgumentError(
"Invalid prompt response type, must be one of [yes, no]".to_string(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could also be prompt right?

@fgrust fgrust requested review from banool and removed request for gregnazario, bchocho, msmouse, lightmark, davidiw, clay-aptos and zekun000 November 23, 2022 15:57
@banool
Copy link
Contributor

banool commented Nov 27, 2022

Awesome work, this looks like it is good to go to me! My only concern now is if this PR lands, users might think the feature is ready, but it doesn't actually affect anything yet. Could you perhaps stack then next PR on top of this one and then we'll land them all together?

@fgrust
Copy link
Contributor Author

fgrust commented Nov 28, 2022

Awesome work, this looks like it is good to go to me! My only concern now is if this PR lands, users might think the feature is ready, but it doesn't actually affect anything yet. Could you perhaps stack then next PR on top of this one and then we'll land them all together?

Sure thing!. I am doing the exact implementation. thanks.

@fgrust
Copy link
Contributor Author

fgrust commented Nov 28, 2022

I thought prompt_yes_with_override function in common/utils.rs is good place to overwrite prompt_options parameter and run. do you have the better idea? this line

}

if !prompt_options.assume_yes {
match GlobalConfig::load()?.get_default_prompt_response() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of points here:

First, GlobalConfig only reads the config at the global folder (e.g. ~/.aptos), we want to read the correct config based on scope. So if there is an .aptos dir in the current dir, use that. You want something like this instead:

let config = CliConfig::load(ConfigSearchMode::CurrentDirAndParents)?;

Second, we shouldn't load the config here, it should be passed in, since in some cases we might already have it. That way we avoid unnecessary double reads of the config.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First - As default_prompt_response is saved in global config file, I think using GlobalConfig::load rather makes sense. CliConfig::load loads the profiles only. Otherwise, it should be stored in the profiles as needed.
Second - I agree with your principle. GlobalConfig::load is used to get .aptos folder path mostly to load profiles, save them, and check the config existence and called more than once to load and then save in a line. Furthermore, it's not designed to pass the global config from the root to the leaf, which means it should be redesigned and/or needed much updates relatively.

@banool, thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First: Okay I may be misunderstanding the code, I'd have to dive deeper. Though for now I'll invoke @gregnazario to comment since he knows the CLI better than anyone 😛

Second: Same thing, what do you think @gregnazario? I see instances where we have a config already, it seems redundant to load it again. Perhaps the config object should be smarter and act as a passthrough cache.

Copy link
Contributor

@gregnazario gregnazario Dec 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay, been very very busy.

I would put it in the global config like he does here, and I think it's the right choice.

This code maybe should read a slightly different way. This will let you override via CLI flags default behavior even if you sent it, allow you to set a default which overtakes so you don't need to send flags, and allow for default prompting otherwise.

This pseudocode below I think lets it be very simple and straightforward for someone to read afterwards and tell what's going on.

// Handle CLI flags
If assume_no:
 return abort
else if assume_yes:
 return Ok

// Then handle default or prompt behavior
bool is_yes = if let Some(response) = default_response:
  response
else:
  prompt and get response

if is_yes:
  return Ok
else:
  return abort

I see now you have Prompt as an option, then replace the end there with a match statement

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the reply. I just did some changes. could you please review again?

@gregnazario gregnazario enabled auto-merge (squash) December 6, 2022 05:28
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

auto-merge was automatically disabled December 6, 2022 07:13

Head branch was pushed to by a user without write access

@banool banool enabled auto-merge (squash) December 6, 2022 14:40
auto-merge was automatically disabled December 6, 2022 14:57

Head branch was pushed to by a user without write access

@banool banool enabled auto-merge (squash) December 6, 2022 14:59
@banool banool disabled auto-merge December 6, 2022 16:53
@banool banool enabled auto-merge (squash) December 6, 2022 16:53
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions
Copy link
Contributor

github-actions bot commented Dec 6, 2022

✅ Forge suite land_blocking success on f1a570fa1109dcebdc096b0e29a7c8c539fda56c

performance benchmark with full nodes : 6819 TPS, 5816 ms latency, 9700 ms p99 latency,no expired txns
Test Ok

@github-actions
Copy link
Contributor

github-actions bot commented Dec 6, 2022

✅ Forge suite compat success on testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> f1a570fa1109dcebdc096b0e29a7c8c539fda56c

Compatibility test results for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> f1a570fa1109dcebdc096b0e29a7c8c539fda56c (PR)
1. Check liveness of validators at old version: testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b
compatibility::simple-validator-upgrade::liveness-check : 7144 TPS, 5406 ms latency, 7100 ms p99 latency,no expired txns
2. Upgrading first Validator to new version: f1a570fa1109dcebdc096b0e29a7c8c539fda56c
compatibility::simple-validator-upgrade::single-validator-upgrade : 4826 TPS, 8246 ms latency, 10700 ms p99 latency,no expired txns
3. Upgrading rest of first batch to new version: f1a570fa1109dcebdc096b0e29a7c8c539fda56c
compatibility::simple-validator-upgrade::half-validator-upgrade : 4828 TPS, 8258 ms latency, 10900 ms p99 latency,no expired txns
4. upgrading second batch to new version: f1a570fa1109dcebdc096b0e29a7c8c539fda56c
compatibility::simple-validator-upgrade::rest-validator-upgrade : 6799 TPS, 5650 ms latency, 10000 ms p99 latency,no expired txns
5. check swarm health
Compatibility test for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> f1a570fa1109dcebdc096b0e29a7c8c539fda56c passed
Test Ok

@banool banool disabled auto-merge December 6, 2022 18:08
@banool banool merged commit 73c9034 into aptos-labs:main Dec 6, 2022
@fgrust fgrust deleted the prompt_response_option branch December 7, 2022 21:07
areshand pushed a commit to areshand/aptos-core-1 that referenced this pull request Dec 18, 2022
…mand (aptos-labs#5614)

* [cli] add default_prompt_response option to set_global_config

* update options

* update global config struct

* add prompt response getter

* apply default prompt option config

* update prompt func

* update prompt func

* fix lint issue

* fix lint error
@Markuze Markuze mentioned this pull request Dec 26, 2022
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.

3 participants