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