Dmitriy, I confirm the first issue but did not get to the bottom of it yet; will keep you posted.
вт, 27 авг. 2019 г. в 17:34, Dmitriy Pavlov <dpav...@apache.org>: > 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 > > >
