Hi William,
On Thu, May 24 2018 at 09:06:14 +1000, William Brown <william(a)blackhats.net.au>
wrote:
On Wed, 2018-05-23 at 11:34 +0200, Viktor Ashirov wrote:
> Hi,
>
> I'd like to continue our discussion about feature parity with perl
> tools
> and overall user experience of the new CLI tools.
>
> Here are some projects where we can take inspiration for our own
> design:
>
> * bpython interpreter
>
https://bpython-interpreter.org/screenshots.html
>
> * fish shell
>
http://fishshell.com/docs/current/design.html
>
> * Python Prompt Toolkit
>
https://github.com/jonathanslenders/python-prompt-toolkit
> (it's used to build tools like pgcli and mycli:
https://github.com/
> dbcli)
>
> * OpenStack CLI:
>
https://docs.openstack.org/python-openstackclient/pike/cli/commands
> .html
>
https://docs.openstack.org/python-openstackclient/pike/cli/interact
> ive.html
>
> Common theme is that all of these CLIs are primarily used in REPL
> mode,
> but they can be used in script mode as well.
>
> Here's the quote from fish shell's design page about the law of
> discoverability:
>
> * Everything should be tab-completable, and every tab completion
> should
> have a description.
>
> * Every syntax error and error in a built-in command should contain
> an
> error message describing what went wrong and a relevant help page.
> Whenever possible, errors should be flagged red by the syntax
> highlighter.
>
> * The help manual should be easy to read, easily available from the
> shell, complete and contain many examples
>
> * The language should be uniform, so that once the user understands
> the
> command/argument syntax, they will know the whole language, and be
> able to use tab-completion to discover new features.
>
Hey there,
When building these tools I took a lot of inspriation from the
openshift tools actually, but there is a logic to the design.
I like the design of
openshift tools, but I think we have a flaw in our
implementation of this logic.
Everything goes from "least specific" to "most
specific"
So for example,
dsctl start <instance>
This doesn't make sense because you have a "specific" action, before
the "broad concept" of an instance.
So everything is in the pattern of:
dsctl <instance> start/thing ....
dsidm <instance> user create ....
Everything goes from least specific to most.
You treat <instance> as a broad concept, when in fact it is a parameter
that is a subject to change. We should use keyword, not a parameter.
Here are few problems with the current design:
* dsctl has "remove" subcommand, but "create" is separate in dscreate
command.
It can be solved with the same logic that you mentioned above:
dsctl instance create ...
dsctl instance remove <instance>
We can prepend all instance specific tasks with "instance" word, we can
even short it to "inst" or "i", similar to GDB commands for those,
who
doesn't like type. So we have a broad concept of "instance", and
specific actions are followed by parameters like instance name.
* "dsctl <instance> status" shows only one instance status, and there is
no easy way to get status of all instances on the server, besides
falling back to systemctl.
Consider this:
dsctl status -- shows status of all instances
dsctl status <instance1> <instance2> .. <instanceN> -- shows status of
specified instances
I actually did put a lot of work into these based on design
principles
already. About all we are missing is tab complete, and IIRC there is a
python argparse module for that which should work given our design.
I'm not
sure how argparse can help here, because in that case we're
relying on shell's support for autocompletion. It might not work, it
might be not enabled. Moreover, "ds" namespace is overloaded. Here's the
output on my F28 box:
# ds <TAB>
ds-cockpit-setup dsidm ds_selinux_port_query
dsconf ds-logpipe.py ds_systemd_ask_password_acl
dscreate ds-replcheck
dsctl ds_selinux_enabled
Some of these commands are moved to a proper place in master, but that
still leaves us with at least:
dsconf
dscreate
dsctl
dsidm
Without looking at man pages (which do not exist, btw), it's hard to
tell what each of these commands does. What's the difference between
dsctl and dsconf? I need to run all of these with --help to get more
information.
In REPL mode I can press <TAB> and get context-aware help and
autocompletion.
I don't REPL mode is super important, I don't think I've EVER used a
REPL in all my years as a sysadmin because I want to be able to copy
paste out whole command sequences.
Your shell is REPL! Did you use shell? :)
Look at openstack cii. You can use it as REPL mode with
tab-completion:
$ openstack
(openstack) server <TAB>
add fixed ip image create resume
add floating ip list set
add port lock shelve
add security group migrate show
add volume pause ssh
backup create reboot start
create rebuild stop
delete remove fixed ip suspend
dump create remove floating ip unlock
event list remove port unpause
event show remove security group unrescue
group create remove volume unset
group delete rescue unshelve
group list resize
group show restore
(openstack) server
or just from the command line:
$ openstack server list
...
If you want to copy-paste commands from the docs - no problem.
If you want to save history, prompt_toolkit provides very nice interface
for that:
http://python-prompt-toolkit.readthedocs.io/en/master/pages/building_prom...
Paged output, editing current command in $EDITOR (similar to C-x C-e in
bash), etc.
I also would really love to get back interactive installer. Installation
from the template is nice, but it has its own issues.
For example, dscreate provides only 2 actions: show an example INI file
and load INF file. Are these two files different? Anyway, let's try to
run
$ dscreate example
...
Here's the wall of text
...
This should be more helpful and at least provide a hint, that this
output should be redirected to a file, since later it will be loaded by
'fromfile' subcommand.
Anyway, let's look at the file. It's very nice documented! Look at all
the options! Some of them are uncommented, that must be required
parameters. But ports are commented, are they not required? Maybe
something else I should change? And the DM's password is in a plain
text. Can I pass hashed value here? Can I be asked for the password so
that it won't be sitting in the template on a filesystem for ages until
someone discovers this template?
Let's change port at least to something else and run dscreate.
# dscreate fromfile localhost.ini
READY: Preparing installation for localhost
READY: Beginning installation for localhost
Job for dirsrv(a)localhost.service failed because the control process exited with error
code.
See "systemctl status dirsrv(a)localhost.service" and "journalctl -xe"
for details.
Error: Command '['/usr/bin/systemctl', 'start',
'dirsrv@localhost']' returned non-zero exit status 1.
FAIL: Command failed. See output for details.
# ausearch -m AVC
----
time->Thu May 24 02:20:39 2018
type=AVC msg=audit(1527142839.292:366): avc: denied { name_bind } for pid=3598
comm="ns-slapd" src=1389 scontext=system_u:system_r:dirsrv_t:s0
tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0
Alright, now I need to make SELinux happy, label ports manually with
ldap_port_t...
Now, I think it would be nice to have something like this in addition to
the unattended install, instead of having unattended mode as the only
way to create an instance.
DS> instance create --name=master1 --fqdn=server.example.com --port=1389
--secure-port=1636 --suffix=dc=example,dc=com --password=
or
# ds instance create --name=master1 --fqdn=server.example.com --port=1389
--secure-port=1636 --suffix=dc=example,dc=com
Enter Directory Manager's password:
...
Hope that helps!
> Please let me know what do you think.
>
> Thanks!
>
> --
> Viktor
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.o
> rg
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives:
https://lists.fedoraproject.org/archives/list/389-deve
> l(a)lists.fedoraproject.org/message/QFJVIX5CTRPBA2VPZIEXUDCZG7L2TS2O/
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...