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
