ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0
Date Thu, 24 Jan 2019 20:01:35 GMT
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 <skozlov@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 <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