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.
--
Sincerely,
William Brown
Software Engineer
Red Hat, Brisbane
No comments:
Post a Comment