FR: rlock command line improvements

[pgagne]

I wanted to file this Feature Request to discuss some improvements that I think could be make to rlock

I can probably do help with this time permiting, or help with it. But if anyone else wants to take it on feel free to contribute.

Currently if one wants to lock a resource, they must type this very long and complicated command:

rlock --lock --server-url=<http url> --token=<long api token> --search-string=aws-resource-1 --priority=1 --signoff=pgagnesign1  --interval=100 --attempts=100

Despite being --options some of these items are required, although not for all operations

This is fine if your looking a resource in something like a jenkins pipeline but can be a bit unweildy when trying to do it from your workstation or in a personal script.

Here are some things I think we should consider fixing, in rough order of importance. There are probably others I'm forgetting, and will probably come across more as LNST works with ResourceLocker more, if others have additional suggestions please comment.

1. Better handling and checking of args.

See #18 . This could probably using something like urllib.parse.urljoin when working with urls.

2. Separate sub-commands

Currently the core functions of locking, checking and releasing are done via options like --lock --check and --release these would probably be better implemented as argparse subcommands: rlock lock , rlock check , rlock release.

This would also allow better handling of required values and would allow them to not have be specified as --options which goes against standard practice and argparse recommandions

For example the above command would look something like (assuming 3 is also implemented)

rlock lock <search string> <signoff> 
rlock lock aws-resource-1 pgagnesign1

We would probably have to think about how to handling existing scripts for this. If those aren't easily updated I purpose we create a new executable called something like rlock2 with the new argument form. Although we might be able to do it in such a way where both subcommands and --lock style operations are supported (with proper deprecation warnings) for a while.

3. Configuration files for common arguments.

We should consider allowing for a simple config file (ie ~/.rlock.conf, ~/.config/rlock.conf or $PWD/rlock.conf to allow someone to specify options like server_url , and perhaps defaults for things like attempts and interval. Specifying options on the command line would take priority over config.

This config file could also potentially be used by rlockerservices

If someone is knowledgeable about an easy way of saving/retrieving secrets like token this from a system keystore please let me know.