ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Artem Budnikov <a.budnikov.ign...@gmail.com>
Subject Re: Control.sh usability & possible bugs
Date Tue, 27 Aug 2019 14:29:50 GMT
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" <dpavlov@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

Mime
View raw message