ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Kozlov <skoz...@gridgain.com>
Subject Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0
Date Thu, 24 Jan 2019 15:05:37 GMT
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 <antonovsergey93@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 <akuznetsov@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 <dmagda@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 <skozlov@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 <
> > > stanlukyanov@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 <
> > > stanlukyanov@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message