When it comes to CLI commands - I would highly recommend to stick to a traditional Unix/Linux approach of command line interfaces and REPLs (i.e. command + zero or more parameters). Nested commands are not a good idea IMHO as they are very hard to document or remember. aws-cli or az have them - but it doesn't make it a good idea...
The main goal of our CLI tool should be simplicity and usability. My 2 cents, -- Nikita Ivanov On Mon, Dec 21, 2020 at 8:35 AM Kirill Gusakov <kgusa...@gmail.com> wrote: > Hey. > > 1. Sure, will remove demo suffixes. > > 2. I thought about it. Not sure why “node-start” is better than “node > start”. > > In general, we really have a subcommands hierarchy and I think it is ok not > to hide it. > > Many tools with subcommands use the same approach: az (azure), aws, docker, > kubectl, git (partially). > > I think it will be a regular pattern for our users. > > But I agree that some confusion can be connected with the usage message, > which provides the info only about 1 level of commands. > > So, to investigate the commands we need to type it and get usage one more > time. > > Also, we shouldn’t increase the depth of the current hierarchy, I think. > > Maybe we should show the grouped sections with subcommands help for the > current approach and it will be good from all points of view, wdyt? > > > On Mon, Dec 21, 2020 at 3:32 AM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Hi Kirill, > > > > It looks like the PR has been merged - thanks a lot for the effort! > > > > A couple of things: > > > > 1. Can we get rid of the word "demo" in the module name? It looks like > > this is an artifact from the times when it was merely a prototype. > This > > is > > not the case anymore. > > 2. The command structure seems a little bit convoluted. How about we > > flatten it and get rid of subcommands? Instead of 'node start' we can > > have > > 'node-start', instead of 'config set' - 'config-set'. We can then > group > > them in the help output so that it's clear that some commands are > > related > > to each other. What do you think? > > > > -Val > > > > On Thu, Dec 17, 2020 at 11:21 AM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Thanks, Kirill! Hopefully, this will be merged soon. > > > > > > -Val > > > > > > On Wed, Dec 16, 2020 at 4:54 AM Kirill Gusakov <kgusa...@gmail.com> > > wrote: > > > > > >> Hi, Valentin. > > >> > > >> PR is ready for review, some smoke tests added. > > >> > > >> On Sat, Dec 12, 2020 at 2:40 AM Valentin Kulichenko < > > >> valentin.kuliche...@gmail.com> wrote: > > >> > > >> > Hi Kirill, > > >> > > > >> > I've played with the tool a little bit and it looks great! I > > definitely > > >> > like the overall approach of a single script responsible for all the > > >> > operations. This should significantly improve the usability of the > > >> product. > > >> > > > >> > Looks like there is a significant amount of functionality already > > >> > implemented. I think we should merge the code to the main branch so > > that > > >> > any other contributors could also participate and build on top of > it. > > >> What > > >> > do you think? Is the PR ready for review? > > >> > > > >> > -Val > > >> > > > >> > On Fri, Dec 11, 2020 at 8:55 AM Kirill Gusakov <kgusa...@gmail.com> > > >> wrote: > > >> > > > >> > > Hi, everyone. > > >> > > > > >> > > I want to propose for discussion the PoC cli tool, which was born > to > > >> > check > > >> > > and demonstrate approaches explained in [0] and [1]. > > >> > > This tool will be the all-in-one cli tool for ignite cluster > > >> management > > >> > and > > >> > > ignite installation/update. > > >> > > > > >> > > One unified tool will: > > >> > > - lower the entry threshold for Ignite newbies (it should be as > > >> simple as > > >> > > wget ignite && ignite init && ignite node start new-node) > > >> > > - be the one entry point for any ignite operation > > >> > > - be used for the smooth automated upgrade of local nodes and > > modules > > >> > > - use abstract REST API for communication with nodes in the > future. > > >> so, > > >> > you > > >> > > can implement your own processes around this REST API if needed > > >> > > > > >> > > Work in progress PR can be found here > > >> > > https://github.com/apache/ignite-3/pull/4 > > >> > > > > >> > > You can: > > >> > > - see a small demo here https://asciinema.org/a/378647 > > >> > > - build it from the PR and try it by yourself > > >> > > > > >> > > For building it from the sources and have a fully working demo > setup > > >> you > > >> > > need firstly: > > >> > > - "mvn install" the root dir here > > >> > > https://github.com/apache/ignite-3/pull/5 > > >> > > - "mvn install" the root dir here > > >> > > https://github.com/apache/ignite-3/pull/6 > > >> > > - "mvn install" tool itself from > > >> > https://github.com/apache/ignite-3/pull/4 > > >> > > > > >> > > > > >> > > [0] > > >> > > > > >> > > > >> > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158873958 > > >> > > [1] > > >> > > > > >> > > > > >> > > > >> > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration > > >> > > > > >> > > > >> > > > > > >
