On Fri, 2016-08-19 at 11:21 +0200, Ludwig Krispenz wrote: > Hi William, > > On 08/19/2016 02:22 AM, William Brown wrote: > > On Wed, 2016-08-17 at 14:53 +1000, William Brown wrote: > >> https://fedorahosted.org/389/ticket/48951 > >> > >> https://fedorahosted.org/389/attachment/ticket/48951/0001-Ticket-48951-dsadm-and-dsconf-base-files.patch > >> https://fedorahosted.org/389/attachment/ticket/48951/0002-Ticket-48951-dsadm-and-dsconf-refactor-installer-cod.patch > >> https://fedorahosted.org/389/attachment/ticket/48951/0003-Ticket-48951-dsadm-and-dsconf-Installer-options-mana.patch > >> https://fedorahosted.org/389/attachment/ticket/48951/0004-Ticket-48951-dsadm-and-dsconf-Ability-to-unit-test-t.patch > >> https://fedorahosted.org/389/attachment/ticket/48951/0005-Ticket-48951-dsadm-and-dsconf-Backend-management-and.patch > >> > >> > > As a follow up, here is a design / example document > > > > http://www.port389.org/docs/389ds/design/dsadm-dsconf.html > thanks for this work, it is looking great and is something we were > really missing. > > But of course I have some comments (and I know I am late). > - The naming dsadm and dsconf, and the split of tasks between them, is > the same as in Sun/Oracle DSEE, and even if there is probably no legal > restriction to use them; I'd prefer to have own names for our own tools. Fair enough. There is nothing saying these names are stuck in stone right now so if we have better ideas we can change it. I will however say that any command name, should not start with numbers (ie 389), and that it should generally be fast to type, easy to remember and less than 8 chars long if possible. > - I'm not convinced of splitting the tasks into two utilities, you will > have different actions and options for the different > resources/subcommands anyway, so you could have one for all. The issue is around connection to the server, and whether it needs to be made or not. The command in the code is: dsadm: command: action dsconf: connect to DS command action So dsconf takes advantage of all the commands being remote, so it shares common connection code. If we were to make the tools "one" we would need to make a decorator or something to repeat this, and there are some other issues there with the way that the argparse library works. > Also, I think, the goal should be to make all actions available local > and remote, the start/stop/install should be possible remotely via rsh > or another mechanism as long as the utilities are available on the > target machine, so I propose one dsmanage or 389manage dsmanage is an okay name but, remote start stop is not an easy task. At that point, you are looking at needing to ssh, manage the acceptance of keys, you have to know the remote server ds prefix, you need to ssh as root (bad) or manage sudo (annoying). You need to potentially manage selinux, systemd etc. It gets really complicated, really fast, and at that point I'm going to turn around and say "no, just use ansible if you want to remote manage things". Lets keep these tools simple as we can, and let things like ansible which is designed for remote tasks, do their job. A better strategy is that we can potentially write a lib389 ansible module in the future allowing us to playbook tasks for DS..... This is why I kept them separate, because I wanted to have simple, isolated domains in the commands for actions, that let us know clearly what we are doing. It's still an open discussion though. > - could this be made interactive ? run the command, providing some or > none options and then have a shell like env > dsmanage > >>> help > ...... connect > ...... create-xxxxx > >>> connect -h .... > ....... replica-enable .... In the current form, no. However, the way I have written it, we should be able to pretty easily replace the command line framework on front and drop in something that does allow interactive commands like this. I was thinking: https://github.com/Datera/configshell This is already in EL, as it's part of the targetcli application. I would rather not have the >>> list Error: no connection >>> connect ldap://localhost password: >>> list ..... Because now there are two states to every command, one connected, one not. Much, much easier for us to develop and reason about if we make connection part of the shell startup, so every command just "knows" it's connected, and errors from that point really are errors. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
