[389-devel] Re: Please review: 48951 dsconf and dsadm foundations
On 08/22/2016 05:23 PM, William Brown wrote: On Sun, 2016-08-21 at 21:33 -0600, Rich Megginson wrote: On 08/21/2016 09:02 PM, William Brown wrote: Anything that is yum, systemd command, etc. is ansible. Anything about installing an instance or 389 specific we do. I think that is an arbitrary line of demarcation. ansible can be used for a lot more than that. Yes it can. But I don't have infinite time, and neither does the team. Lets get something to work first, then we can grow what ansible is able to integrate with. Lets design our code to be able to be integrate with ansible, but draw some basic lines on things we shouldn't duplicate and then remove in the future. This is why I want to draw the line that start/stop of the server, and certain remote admin tasks aren't part of the scope here. Saying this, in a way I'm not a fan of this also. Because we are doing behind the scenes magic, rather than simple, implicit tasks. What happens if someone crons this? What happens? We lose the intent of the admin in some cases. I think the principle should be "make it simple to do the easy things - make it possible to do the difficult things". In this case, if I am an admin running a cli, I think it should "do the right thing". If I'm setting up a cron job, I should be able to force it to use offline mode or whatever - it is easy to keep track of extra cli arguments if I'm automating something vs. running interactively on the command line. I agree with that principle, and is actually one of the guides I am following in my design. I think that here, we have a differing view of simple. My interpretation is. My idea of simple is "each task should do one specific thing, and do it well". you have db2ldif and db2ldif_task. Each one just does that one simple thing. The intent of the admin is clear at the moment they hit enter. Not if they don't know what is meant by "_task". It might as well be ".pl" to most admins. Most of the admins I've encountered say "I just want to get an ldif dump from the server - I have no idea what is the difference between db2ldif and db2ldif.pl." I think they will say the same thing about "db2ldif" vs. "db2ldif_task". I was thinking about this, this morning, and I think I have come to agree with you. Lets make this "you want to get from A to B, and we work out how to get there". Similar to ansible, which probably lends well to use using ansible in the future for things. Your idea of simple is "intuitive simple" for the admin, where behaviours are inferred from running application state. The admin says "how I want you to act" and the computer resolves the path to get there. And - if the admin knows the tool, because the admin has learned by experience, progressive disclosure, or RTFM, the admin can explicitly specify the exact modes of operation using command line flags. Using the tool simply is easy, using the tool in an advanced fashion is possible. I think the intent of the tool should be clear without huge amounts of experience and rtfm. We have a huge usability and barrier to entry problem in DS, and if we don't make changes to lower that, we will become irrelevant. We need to make it easier to use, while retaining every piece of advanced functionality that our experienced users expect :) (I think we agree on this point though) One day we will need to make a decision on which way to go with these tools, and which path we follow, but again, for now it's open. Of course, I am going to argue for the former, because that is the construction of my experience. Reality is that I've seen a lot of production systems get messed up because what seemed intuitive to the programmer, was not the intent of the admin. We are basically having the "boeing vs airbus" debate. Boeing has autopilots and computer assistance, but believes the pilot is always right and will give up control even if the pilot is going to do something the computer disagrees with. Airbus assumes the computer is always right, and will actively take control away from the pilot if they are going to do something the computer disagrees with. It's about what's right: The program? Or the human intent? And that question has never been answered. I think the discussion doesn't fall exactly on the "boeing vs airbus" axis, but perhaps isn't entirely orthogonal either. As said above, I think maybe we should go down the "programmer is right" idea, but with the ability for the sysadmin to take over if needed. +1 - I think you've got the right idea. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
[389-devel] Re: Please review: 48951 dsconf and dsadm foundations
On 08/21/2016 09:56 PM, William Brown wrote: > On Sun, 2016-08-21 at 19:44 -0600, Rich Megginson wrote: >> On 08/21/2016 05:28 PM, William Brown wrote: >>> 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. >> What about "adm389" and "conf389"? > Yeah, those could work. What about something like: "dsctl", and "dscfg" ? Mark > - 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. >> I think this is an arbitrary distinction - needing a connection or not - >> but other projects use similar "admin client" vs. "more general use >> client" e.g. OpenShift has "oadm" vs. "oc". If this is a pattern that >> admins are used to, we just need to be consistent in applying that pattern. >> >>> 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). >> We already have the ability to remote stop/start/restart the server, >> with admin server at least. > Not with systemd we don't. systemd + selinux has broken that for a stack > of our products, and at the moment, we are publishing release notes that > these don't work in certain cases. And rightly so, ds should not have > the rights to touch system services in the way we were doing, it's a > huge security risk. > > To make it work we need to do dbus and polkit magic, and the amount of > motivation I have to give about this problem is low, especially when > tools like ansible do it for us, much better. > >>> 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. >> Right, but it will take a lot of work to determine what should be done >> in ansible vs. specialized tool. > Not really. An admin will know "okay, if I want to start stop services I > write action: service state=enabled dirsrv@instance". They will also > know "well I want to reconfigure plugins on DS, I use conf389/dsconf". > > Anything that is yum, systemd command, etc. is ansible. Anything about >
[389-devel] Re: Please review: 48951 dsconf and dsadm foundations
On 08/21/2016 07:56 PM, William Brown wrote: On Sun, 2016-08-21 at 19:44 -0600, Rich Megginson wrote: On 08/21/2016 05:28 PM, William Brown wrote: 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. What about "adm389" and "conf389"? Yeah, those could work. - 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. I think this is an arbitrary distinction - needing a connection or not - but other projects use similar "admin client" vs. "more general use client" e.g. OpenShift has "oadm" vs. "oc". If this is a pattern that admins are used to, we just need to be consistent in applying that pattern. 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). We already have the ability to remote stop/start/restart the server, with admin server at least. Not with systemd we don't. systemd + selinux has broken that for a stack of our products, and at the moment, we are publishing release notes that these don't work in certain cases. And rightly so, ds should not have the rights to touch system services in the way we were doing, it's a huge security risk. To make it work we need to do dbus and polkit magic, and the amount of motivation I have to give about this problem is low, especially when tools like ansible do it for us, much better. 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. Right, but it will take a lot of work to determine what should be done in ansible vs. specialized tool. Not really. An admin will know "okay, if I want to start stop services I write action: service state=enabled dirsrv@instance". They will also know "well I want to reconfigure plugins on DS, I use conf389/dsconf". Anything that is yum, systemd command, etc. is ansible. Anything about installing an instance or 389 specific we do. I think that is an arbitrary line of demarcation. ansible can be used for a lot more than that. A better strategy is that we can potentially write a lib389 ansible module in the future allowing us to playbook tasks for DS. I would like to see ansible playbooks for 389. Ansible is python, so we can leverage python-ldap/lib389
[389-devel] Re: Please review: 48951 dsconf and dsadm foundations
On Sun, 2016-08-21 at 19:44 -0600, Rich Megginson wrote: > On 08/21/2016 05:28 PM, William Brown wrote: > > 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. > > What about "adm389" and "conf389"? Yeah, those could work. > > > > >> - 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. > > I think this is an arbitrary distinction - needing a connection or not - > but other projects use similar "admin client" vs. "more general use > client" e.g. OpenShift has "oadm" vs. "oc". If this is a pattern that > admins are used to, we just need to be consistent in applying that pattern. > > > > > > >> 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). > > We already have the ability to remote stop/start/restart the server, > with admin server at least. Not with systemd we don't. systemd + selinux has broken that for a stack of our products, and at the moment, we are publishing release notes that these don't work in certain cases. And rightly so, ds should not have the rights to touch system services in the way we were doing, it's a huge security risk. To make it work we need to do dbus and polkit magic, and the amount of motivation I have to give about this problem is low, especially when tools like ansible do it for us, much better. > > > 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. > > Right, but it will take a lot of work to determine what should be done > in ansible vs. specialized tool. Not really. An admin will know "okay, if I want to start stop services I write action: service state=enabled dirsrv@instance". They will also know "well I want to reconfigure plugins on DS, I use conf389/dsconf". Anything that is yum, systemd command, etc. is ansible. Anything about installing an instance or 389 specific we do. > > > > > A better strategy is that we can potentially write a lib389
[389-devel] Re: Please review: 48951 dsconf and dsadm foundations
On 08/21/2016 05:28 PM, William Brown wrote: 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. What about "adm389" and "conf389"? - 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. I think this is an arbitrary distinction - needing a connection or not - but other projects use similar "admin client" vs. "more general use client" e.g. OpenShift has "oadm" vs. "oc". If this is a pattern that admins are used to, we just need to be consistent in applying that pattern. 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). We already have the ability to remote stop/start/restart the server, with admin server at least. 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. Right, but it will take a lot of work to determine what should be done in ansible vs. specialized tool. A better strategy is that we can potentially write a lib389 ansible module in the future allowing us to playbook tasks for DS. I would like to see ansible playbooks for 389. Ansible is python, so we can leverage python-ldap/lib389 instead of having to fork/exec ldapsearch/ldapmodify. 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. If this is a common patterns that admins are used to, then we should consider it. - could this be made interactive ? run the command, providing some or none options and then have a shell like env dsmanage >>> help .. connect .. create-x >>> 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. Think MVC - just make sure you can change the View. I tried to do this with setup-ds.pl - make it possible to "plug in" a different "UI".
[389-devel] Re: Please review: 48951 dsconf and dsadm foundations
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-x > >>> 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 signature.asc Description: This is a digitally signed message part -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
[389-devel] Re: Please review: 48951 dsconf and dsadm foundations
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. - 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. 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 - could this be made interactive ? run the command, providing some or none options and then have a shell like env dsmanage >>> help .. connect .. create-x >>> connect -h ... replica-enable ? More details to come. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
[389-devel] Re: Please review: 48951 dsconf and dsadm foundations
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 More details to come. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane signature.asc Description: This is a digitally signed message part -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
