On Fri, May 24, 2019 at 09:50:48AM -0400, Mark Reynolds wrote: > On 5/22/19 9:02 PM, William Brown wrote: > > Hi all, Hi William, > > I would propose to change this - but I feel we are now wedged on change by two things: > > > > * Red Hat have documented these tools, and it's a big ask to get them to re-document everything. > > * The cockpit console uses these tools in a special --json mode ( I would have created a dscockpit command that just handled the --json mode, rather than trying to make a tool do two jobs well.). This means rewriting cockpit integration .... > There was a brief talk about this actually while you were gone. But Admins > could use the json output for these same tasks so we left it in dsconf. I > would not be opposed to doing this though. It would not be a major change > for the UI, but it would be a lot of work to write the tool (alot of > redundancy with dsconf). We also talked about doing bulk data loading, so > we could do something like call "ds-cockpit load replication", or > load-everything, instead of calling "dsconf get" 20 times Ideally, it should be a JSON API, in my opinion. It will give us possibility to imporove CLI as we want (in the future). > > * Time - heaps of time has already gone into these tools now, can we really justify undoing all that effort for this? Yeah, it will require a lot of time to rewrite tools and docs at this point. And I am not even talking about the confusion that it will produce for customers (if we replace the tools too often without very good reason). > > > > > > Which is a bit why I'm writing this > > - Should I stop my task-oriented-vision and complaining that I have been doing, and accept what we have today? > > - Do we want to try and pivot to change based on the ideas I have? > > - Do I build something in parallel to satisfy my selfish desires, and to supplement what we have? > > I really think you should write a new CLI tool that only does your > recipe-style tasks for certain things. Like I said that approach will not > cover everything, but it could be used for other tasks. Let the existing > dsconf handle the fine grained configuration (although it's not as bad as > you make it sound), then have a tool like "dstask", "dsrecipe" or something, > that handles larger replication deployments, or whatever else you wanted to > generalize. > > To be honest I would like to hear from you which exact configurations you > want to change. Give some good detailed examples. You keep saying how we > should use a different style, but I think when you look closely at these > areas of configuration you will find it's not possible to generalize them > and to hide the horrid attributes underneath. IMHO I feel most of the CLI > commands are already doing what you kind of want except for a few of them > which require fine grained control. We can also add new arguments to the > existing commands, but it's a bit late to rewrite/replace all of the usage. > > So I am all for extending/improving the current CLI (it's certainly not > perfect), or even you adding another tool for doing recipe tasks, but > rewriting all of it doesn't sit well with me. > > These are just my (biased) opinions, it would be nice if others from the 389 > team (or anyone) would speak up and voice their opinions and perspectives... > > Mark So, the discussion is back :) Last time I remember it has happend here - https://pagure.io/389-ds-base/pull-request/50218 First of all, I think we can improve the existing tool. The ideal picture I have in my head is: - Optional arguments used only when they are really optional. A good example - `oc` OpenShift CLI. Just check its help and functionality... Sometime it has 3-5 positional arguments but the `--help` is so nice and verbose that it is pleasure to use it (and if we add a bash-complition - it will be even better) - Everything should be consistent. If we use one approach, we should stick to it accross the whole tool (we have small issues with that already but they are not big, fortunatly) - It will be very nice to have an option for interactive session where users can do commands using the same connection. But it is really optional 'nice to have' feature (and it will be nice to have feedbeck from users/customers if they need it at all) - We should move all JSON interactions to the REST API or something like this. And you can find my plan below. (I posted it in the issue above and you said it sounds reasonable to you) I'd like to mention that it is veeery long term plan, we can't rush things here... I'll leave some additional comments too: 1. Document the whole idea with all tools included and commands described (a design doc); Done by you. It is very nice and it can be imporoved even more. Ideally, it should contain the full help descriptions for all tools. This way we can review exact datails of you vision. Also, if you want and I can do some part of the work and write some of my vision too, and maybe it won't be too much different from yours. 2. Then we should as a team agree on the whole idea and details (review of the design doc); 3. Start developing the replacement in a separate branch which is not master; 4. The team will help you as much as it can (depends on the resources and the workload we have). After we have the full design doc - it will be pretty easy to create pagure issues and share them in the team; 5. After it is done and documented - it will be much easier to put it in the following major release (maybe it will be next RHEL? - depends on the fact when it will be really done and ). Still, we should target some release, I think - it will give us more determination. 6. Legacy tools can be depricated afterwards but slowly. Of course, we will give customers a time to adopt the new CLI and depricate the Legacy CLI with a later release. And another pretty important point here, in my opinion (the inial idea was given by Thierry), is the user/customers opinion. I think, first, we should collect the feedback on the new tools and only then plan such a massive changes. We should really be clear about was customers want and how critical it is. Of course, I am opened for the discussion on the plan and the vision. As Mark has pointed out, we should really gather here and decide as a team. :) Regards, Simon
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
