Re: Please review: 48951 dsconf and dsadm foundations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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".


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.


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.





So perhaps again, the dsadm/dsconf distinction is good here.

We can have dsadm always does the "offline" variant, and we can have a
similar command is dsconf that runs the online task.
I don't think that's the right distinction.
See above.



--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-devel@xxxxxxxxxxxxxxxxxxxxxxx


--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-devel@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux