Sergey You're right that both modes would be good to support. My concerns are about the approaches for interactive mode and current implementation for visor cmd looks ugly: in interactive mode you execute command like in command-line: *visor> disco -r -t=2m -c=1*
I think the interactive mode should look close to SQL (but it will require to implement a parser and increase the complexity of development) On Thu, Jan 24, 2019 at 11:36 PM Sergey <macrerg...@gmail.com> wrote: > Hi! > Why should we choose between interactive and command mode? > I'd suggest that new utility doesn't matter of its name control.sh or visor > should have support of both modes. > > Sergey Kosarev > > чт, 24 янв. 2019 г., 23:02 Denis Magda dma...@apache.org: > > > Sergey, > > > > Let's break and rebuild the visor from the ground. It's fine if it > becomes > > incompatible with older versions. > > > > - > > Denis > > > > > > On Thu, Jan 24, 2019 at 7:05 AM Sergey Kozlov <skoz...@gridgain.com> > > wrote: > > > > > Denis > > > > > > I'm not sure that visorcmd can be refactored without incompatible > changes > > > or significant changes for behaviour: > > > 1. Visorcmd starts as demon node and joins the cluster. The modern > > > utilities don't need spring config and just connect to TCP management > > port. > > > 2. Visorcmd is mostly an interactive tool but control.sh looks like > *nix > > > regular command-line program. > > > 3. Visorcmd command set (IMO) is weird and has some commands that > > sometimes > > > are not about ignite (like deploy - copy file to remote nodes) or not > > clear > > > why we need them (mlist/mget/mcompact) > > > > > > I think we should define the root purpose for new utility (or for > > > refactored visorcmd) > > > From my standpoint they are following: > > > - cluster status commands (topology, node status, configuration, etc) > > > - cluster management commands (control.sh baseline commands + visrcmd > > > kill/stop nodes) > > > - cache content commands (print/clear cache content) > > > - cache management commands (create/stop/destroy/copy/rename etc > cache) > > > - service/job management commands (start/stop/restart service/job) > > > - tx management (tx list, kill) > > > - data consistency commands (idle_verify, crc_check, checkpoint) > > > - statistics commands (cluster/cache metrics) > > > > > > > > > > > > > > > On Thu, Jan 24, 2019 at 12:12 PM Sergey Antonov < > > antonovserge...@gmail.com > > > > > > > wrote: > > > > > > > Alexey, Denis I agree yours points. > > > > > > > > I think we should rewrite visor.cmd from scala to java at first. And > > then > > > > merge control.sh into visor.cmd. > > > > > > > > чт, 24 янв. 2019 г. в 11:44, Alexey Kuznetsov <akuznet...@apache.org > >: > > > > > > > > > I agree with Denis, > > > > > > > > > > How about to merge control.sh into Visor.CMD ? > > > > > And rewrite Visor.CMD from Scala to Java. > > > > > > > > > > What do you think? > > > > > > > > > > On Thu, Jan 24, 2019 at 4:41 AM Denis Magda <dma...@apache.org> > > wrote: > > > > > > > > > > > Why don't we go in a reverse direction - instead of creating > > multiple > > > > > > scripts for different needs we incorporate all capabilities > within > > > > > > visorcmd? Visor is an app/script that can be updated to meet the > > > > > > requirements of specific tools. > > > > > > > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Wed, Jan 23, 2019 at 1:23 PM Sergey Kozlov < > > skoz...@gridgain.com> > > > > > > wrote: > > > > > > > > > > > > > Thanks Sergey for the raising the question. > > > > > > > > > > > > > > What's about move actual/interesting commands from visorcmd and > > > > remove > > > > > > that > > > > > > > script at all? > > > > > > > > > > > > > > Also would good simplify the bash code of script and ideally > > > process > > > > > > > everyting inside java code? > > > > > > > > > > > > > > On Wed, Jan 23, 2019 at 7:38 PM Stanislav Lukyanov < > > > > > > stanlukya...@gmail.com > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > I value strict compatibility rules very highly, and would be > > > happy > > > > if > > > > > > we > > > > > > > > never removed a public class (even if it is in the “internal” > > > > > package) > > > > > > > > in a minor release. > > > > > > > > Unfortunately, Ignite is far from that place for now. We > don’t > > > have > > > > > any > > > > > > > > distinction between API and internal classes, don’t have > > > > > > > > plugin-only APIs, etc. All classes are public, everything is > > > > > accessible > > > > > > > to > > > > > > > > user code. We even refer to internal classes in public > Javadoc > > > > > > > > (e.g. I recall mentions of IgniteUtils in examples here and > > > there). > > > > > > > > Considering this, moving CommandHandler from ignite-core to > > > > > > > > ignite-control-utility > > > > > > > > doesn't look that bad. It doesn’t differ to much from any > other > > > > > change > > > > > > > > that removes or renames a class. > > > > > > > > There could be required changes with a higher compatibility > > > impact > > > > > but > > > > > > I > > > > > > > > don’t see them after a superficial glance. > > > > > > > > > > > > > > > > Stan > > > > > > > > > > > > > > > > From: Sergey Antonov > > > > > > > > Sent: 23 января 2019 г. 19:15 > > > > > > > > To: dev@ignite.apache.org > > > > > > > > Subject: Re: [DISCUSSION] Control.sh global rework in apache > > > ignite > > > > > 3.0 > > > > > > > > > > > > > > > > Stan, thank you for response! > > > > > > > > > > > > > > > > I my view we shouldn't make incompatible changes and switch > > > > > extendable > > > > > > > > classes (i.e. VisorDataTransferObject -> > > > IgniteDataTransferObject) > > > > > > > between > > > > > > > > minor releases. Therefore we couldn't rework utility in 2.8 > > > > release. > > > > > > > > > > > > > > > > ср, 23 янв. 2019 г. в 18:48, Stanislav Lukyanov < > > > > > > stanlukya...@gmail.com > > > > > > > >: > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Sounds good. I agree with all points so far. > > > > > > > > > > > > > > > > > > I don’t really see why to wait for 3.0 though. > > > > > > > > > As long as the old commands work I think it’s fine to do > all > > of > > > > > that > > > > > > > in a > > > > > > > > > minor release. > > > > > > > > > > > > > > > > > > Even moving the code to a separate module is fine as all > the > > > > > classes > > > > > > > are > > > > > > > > > internal and unlikely to be used in the wild. > > > > > > > > > On paper it’s an incompatible change, of course, but I > think > > in > > > > > this > > > > > > > case > > > > > > > > > it’s fine. > > > > > > > > > > > > > > > > > > My 2 cents, > > > > > > > > > Stan > > > > > > > > > > > > > > > > > > From: Sergey Antonov > > > > > > > > > Sent: 23 января 2019 г. 17:10 > > > > > > > > > To: dev@ignite.apache.org > > > > > > > > > Subject: [DISCUSSION] Control.sh global rework in apache > > ignite > > > > 3.0 > > > > > > > > > > > > > > > > > > Hello, Igniters! > > > > > > > > > > > > > > > > > > I think, we should rework control.sh utility in Apache > Ignite > > > 3.0 > > > > > > > > release. > > > > > > > > > I made umbrella ticket [1] for it. > > > > > > > > > > > > > > > > > > For a start we should move utitlity from ignite-core to > > > separate > > > > > > module > > > > > > > > > [2]. It's enable using 3rd-party libraries, for example > > > > commons-cli > > > > > > > [3]. > > > > > > > > > > > > > > > > > > Also we should add logging to file [4] and stop using > > > depricated > > > > > > > classes, > > > > > > > > > for example [5]. > > > > > > > > > > > > > > > > > > I'd like to get yours comments about control.sh. > > > > > > > > > > > > > > > > > > Let's collect comments and improvements and discuss them! > > > > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11045 > > > > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-11046 > > > > > > > > > [3] http://commons.apache.org/proper/commons-cli/ > > > > > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-10826 > > > > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-11047 > > > > > > > > > -- > > > > > > > > > BR, Sergey Antonov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > BR, Sergey Antonov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Sergey Kozlov > > > > > > > GridGain Systems > > > > > > > www.gridgain.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Alexey Kuznetsov > > > > > > > > > > > > > > > > > -- > > > > BR, Sergey Antonov > > > > > > > > > > > > > -- > > > Sergey Kozlov > > > GridGain Systems > > > www.gridgain.com > > > > > > -- Sergey Kozlov GridGain Systems www.gridgain.com
