Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0
3, 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
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 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 > 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 : > > > > > > > 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 > 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 cl
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 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 > > 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 : > > > > > 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 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 > > > > 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
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 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 : > > > 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 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 > > > 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 < > > > stanlu
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 : > 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 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 > > 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
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 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 > 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
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 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 > > 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 >: > > > > > 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 >
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 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 : > > > 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
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: 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 : > 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
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 : > 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
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: 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
