Hi William, On Thu, May 24 2018 at 09:06:14 +1000, William Brown <william@xxxxxxxxxxxxxxxx> 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_prompts.html 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@localhost.service failed because the control process exited with error code. See "systemctl status dirsrv@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@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to 389-devel-leave@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@xxxxxxxxxxxxxxxxxxxxxxx/message/QFJVIX5CTRPBA2VPZIEXUDCZG7L2TS2O/ > _______________________________________________ > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx/message/GABWBNQO55TW2OE2PZCT5PI3BJZKXC42/
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx/message/4ESZJFZQAUAMN7XH7GZK4KZOK7FHQVF5/
