Hi Artem, thank you for your reply. Since this change is on its way, let's wait for 2.8.
Petr Ivanov, Alexey Goncharuck, Ivan Rakov, could you please step in and provide your feedback related to Issue 1 & 2? вт, 27 авг. 2019 г. в 17:30, Artem Budnikov <a.budnikov.ign...@gmail.com>: > Hi everyone, > > Re Issue 3: > > That's a good idea, but as far as I remember this was done in > https://jira.apache.org/jira/browse/IGNITE-10279 and is waiting to be > released in Ignite 2.8. > > -Artem > > On 26.08.2019 15:18, Anton Kalashnikov wrote: > > Hello, Igniters. > > > > +1 for Script help usability - issue 3 > > > > Looks like it will be great if we avoid the repeated output of the > commands, ex.: > > > > control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password > PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT] > [<command>] [--yes] > > > > Allowable <command>: > > --activate - ... > > --deactivate - ... > > ... > > > > -- > > Best regards, > > Anton Kalashnikov > > > > > > 26.08.2019, 15:00, "Dmitriy Pavlov" <dpav...@apache.org>: > >> Hi Igniters, > >> > >> During voting on 2.7.6-rc1, I saw how experienced Ignite contributor > >> committer and PMC member were trying to activate cluster using > control.sh > >> command. > >> > >> We usually just call cluster().active(true), but end users have to use > the > >> script provided in the distribution. > >> > >> Related to control.sh there are 3 concerns: > >> > >> Issue 1: On Mac OS if there is an empty (unset) JAVA_HOME variable, > script > >> outputs noting and probably does not execute its comment. > >> > >> Petr Ivanov, Alexey Goncharuck, could you please double-check if it > could > >> be fixed? > >> > >> Issue 2: Control.sh was not able to connect to cluster (local). AFAIK > >> multicast is still our defaults. so it should be possible to connect to > >> cluster without any options. > >> > >> Ivan Rakov, could you please chime in? Is it a local issue or bug? > >> > >> Issue 3: Script help usability > >> > >> Example of output: > >> > >> Activate cluster: > >> > >> control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] > [--password > >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT] > >> --activate > >> > >> Deactivate cluster: > >> > >> control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] > [--password > >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT] > >> --deactivate [--yes] > >> > >> ... > >> > >> Why do we repeat tons of parameters each time? Is it better for users to > >> enlist options and commands separately? > >> > >> control.sh [options] command > >> > >> and then enlist options > >> > >> [--host HOST_OR_IP] > >> > >> [--port PORT] > >> > >> [--user USER] > >> > >> [--password PASSWORD] > >> > >> [--ping-interval PING_INTERVAL] > >> > >> [--ping-timeout PING_TIMEOUT] > >> > >> and describe several commands we have? > >> > >> In coding WET is not the best solution. So maybe we could DRY in our > help, > >> should we? > >> > >> Artem Boudnikov, could you evaluate this idea? > >> > >> Sincerely, > >> Dmitriy Pavlov >
