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

connection cooldown time for local computers? #2880

Closed
ltalirz opened this issue May 16, 2019 · 5 comments · Fixed by #3590
Closed

connection cooldown time for local computers? #2880

ltalirz opened this issue May 16, 2019 · 5 comments · Fixed by #3590

Comments

@ltalirz
Copy link
Member

ltalirz commented May 16, 2019

AiiDa currently configures a connection cooldown time for local computers:

max@ip-172-31-1-140:~$ verdi computer configure local localhost2
Info: enter "?" for help
Connection cooldown time (sec) [2.0]:
Info: Configuring computer localhost2 for user aiida@localhost.
Success: localhost2 successfully configured for aiida@localhost

Not sure this really makes sense... one could leave it as an option for testing but I don't think we should prompt for it.

Also, the help shows the time as an integer, while the default is shown as a float (which makes more sense I find):

max@ip-172-31-1-140:~$ verdi computer configure local -h
Usage: verdi computer configure local [OPTIONS] COMPUTER

  Configure COMPUTER for local transport.

Options:
  -u, --user USER          Email address of the user.
  --safe-interval INTEGER  Minimum time between connections in sec
  -n, --non-interactive    Non-interactive mode: never prompt for input.
  -h, --help               Show this message and exit.
@sphuber
Copy link
Contributor

sphuber commented Jun 5, 2019

The safe_interval is a property of the Transport base class and therefore also needs to be set for the LocalTransport. If we want to keep it configurable, we need to keep the option in the configuration command. Since a default is provided (currently incorrectly set to 2.0) all one has to do is press enter. With the -n flag even this is not necessary. I think that is perfectly acceptable for now.

@ltalirz
Copy link
Member Author

ltalirz commented Jun 5, 2019

Since a default is provided (currently incorrectly set to 2.0)

Ok, so I guess you'll set the default to 0 for local connections? That would already make more sense.

I still think it is preferable that verdi computer configure local does not prompt for it (and silently uses the default). I think in 99% of cases this property does not make sense for a local connection, so we should not show this to users.

@sphuber
Copy link
Contributor

sphuber commented Jun 5, 2019

Yes I am fixing this now, as well as adding additional validation and cleaning things up. Currently you can set it to a negative number for example. It will be difficult to not have this prompt only for the local transport. These configure commands are created dynamically based on the registered transport entry points and the options are created based on the auth options defined in that class. Since this is a property of the base Transport class it will be difficult to hide this just for the local configure command. If this is really necessary, this would require a big rewrite.

@ltalirz
Copy link
Member Author

ltalirz commented Jun 5, 2019

If this is really necessary, this would require a big rewrite.

Ok, then let's not invest time in this right now.

@ltalirz
Copy link
Member Author

ltalirz commented Nov 29, 2019

Since a default is provided (currently incorrectly set to 2.0) all one has to do is press enter. With the -n flag even this is not necessary

Actually, we have just tested this again and this is not correct.
The option is currently required for local computers.

$ verdi computer configure local localhost -n
Usage: verdi computer configure local [OPTIONS] COMPUTER

Error: Missing option "--safe-interval".

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

Successfully merging a pull request may close this issue.

2 participants