Apache Ignite Developers - Legacy Mail Archive

[DISCUSSION] Control.sh global rework in apache ignite 3.0

Classic

List

Threaded

12 messages Options

antonovsergey93

[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

Stanislav Lukyanov

RE: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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: [hidden email]
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

antonovsergey93

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 <[hidden email]>:

> 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: [hidden email]
> 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

Stanislav Lukyanov

RE: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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: [hidden email]
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 <[hidden email]>:

--
BR, Sergey Antonov

Sergey Kozlov

Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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 <[hidden email]>
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: [hidden email]
> 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 <[hidden email]>:
>
> > 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: [hidden email]
> > 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

dmagda

Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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 <[hidden email]> 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 <[hidden email]
> >
> 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: [hidden email]
> > 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 <[hidden email]
> >:
> >
> > > 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: [hidden email]
> > > 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

Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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 <[hidden email]> 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 <[hidden email]>
> 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 <
> [hidden email]
> > >
> > 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: [hidden email]
> > > 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 <
> [hidden email]
> > >:
> > >
> > > > 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: [hidden email]
> > > > 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

antonovsergey93

Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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 <[hidden email]>:

> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <
> > [hidden email]
> > > >
> > > 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: [hidden email]
> > > > 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 <
> > [hidden email]
> > > >:
> > > >
> > > > > 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: [hidden email]
> > > > > 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

Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <
> > > [hidden email]
> > > > >
> > > > 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: [hidden email]
> > > > > 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 <
> > > [hidden email]
> > > > >:
> > > > >
> > > > > > 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: [hidden email]
> > > > > > 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

dmagda

Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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 <[hidden email]> 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 <[hidden email]
> >
> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]> 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 <[hidden email]>
> > > > 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 <
> > > > [hidden email]
> > > > > >
> > > > > 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: [hidden email]
> > > > > > 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 <
> > > > [hidden email]
> > > > > >:
> > > > > >
> > > > > > > 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: [hidden email]
> > > > > > > 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 Kosarev

Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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 [hidden email]:

> 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 <[hidden email]>
> 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 <
> [hidden email]
> > >
> > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>
> 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 <
> [hidden email]>
> > > > > 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 <
> > > > > [hidden email]
> > > > > > >
> > > > > > 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: [hidden email]
> > > > > > > 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 <
> > > > > [hidden email]
> > > > > > >:
> > > > > > >
> > > > > > > > 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: [hidden email]
> > > > > > > > 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

Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0

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 <[hidden email]> 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 [hidden email]:
>
> > 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 <[hidden email]>
> > 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 <
> > [hidden email]
> > > >
> > > 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 <[hidden email]
> >:
> > > >
> > > > > 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 <[hidden email]>
> > 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 <
> > [hidden email]>
> > > > > > 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 <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > 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: [hidden email]
> > > > > > > > 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 <
> > > > > > [hidden email]
> > > > > > > >:
> > > > > > > >
> > > > > > > > > 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: [hidden email]
> > > > > > > > > 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