[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