Closed joshmoore closed 3 years ago
I'll push a refactoring for @sbesson's fairly minor issue but on the API front, all are happy?
/status_check
)Thanks, the option is now properly exposed
(.venv3) bash-4.2$ omero login --help
usage: /home/omero/workspace/OMERO login [-h] [-C] [-s SERVER] [-p PORT]
[-g GROUP] [-u USER] [-w PASSWORD]
[-k KEY] [--sudo ADMINUSER] [-q]
[-t TIMEOUT] [--retry [RETRY]]
[connection]
Login to a given server, and store session key locally.
USER, HOST, and PORT are set as args or in a ssh-style connection string.
PASSWORD can be entered interactively, or passed via -w (insecure!).
Alternatively, a session KEY can be passed with '-k'.
Admin users can use --sudo=ADMINUSER to login for others.
Examples:
omero login example.com
omero login user@example.com
omero login user@example.com:24064
omero login -k SESSIONKEY example.com
omero login --sudo=root user@example
Positional Arguments:
connection Connection string. See extended help for examples
Optional Arguments:
In addition to any higher level options
-h, --help show this help message and exit
-t TIMEOUT, --timeout TIMEOUT Timeout for session. After this many inactive seconds, the session will be closed
--retry [RETRY] Number of seconds to retry login (default: no retry)
...
Thinking more of the question raised https://github.com/ome/omero-py/pull/283#issuecomment-815500432, I tried to look at similar examples. Probably the most relevant to this conversation curl.
A few thoughts:
--retry RETRY
mean the number of actual retries was also my natural expectation when I first tested before reading more closely the description--retry-delay <seconds>
is an option. Note the exponential backoff behavior in curl
(1s, 2s, 4s, 8s, 16s ... 10min) which is enabled by default unless --retry-delay
is set would be interesting to consider--retry
an opt-in via option is completely fine
- looking at the curl documentation, I realized that having
--retry RETRY
mean the number of actual retries was also my natural expectation when I first tested before reading more closely the description
Seems like this is the biggest issue to address since a change would be breaking.
Any thoughts, @sbesson ?
Any thoughts, @sbesson ?
From my side, happy to start with a simple fixed delay and capping based on the total retry time. We can add more complex algorithm or cap the number of retries as follow-up.
I tried to spend a bit of time looking at other examples. Unfortunately, there is no real unified way to specify retry via command-line. Looking at a few examples:
--retry <num> / --retry-max-time <seconds> / --retry-delay <seconds>
--tries=number / --waitretry=seconds
–connect-retry n [max] / –connect-retry-max n
--retries
In the absence of a compromise, maybe --retry <RETRY>
is as good as any. If we decided to implement a configurable number of retries and this becomes confusing, I can imaging we can always deprecate this form in favor of more explicit names e.g. --retry-{max-time/max-count}
.
Ok. Sounds like we have a path forward if we want to become more explicit. Merging and getting this released.
This should replace the wait.sh-stype scripts that exist in multiple (especially docker) repositories.
Example output:
see: https://github.com/ome/omero-server-docker/blob/master/test_login.sh