Re: Control.sh usability & possible bugs
The ticket is created, the patch is attached:
https://issues.apache.org/jira/browse/IGNITE-12113
Also, I see some weird stuff going on in control.sh - I see no reason for
calling findAvailableJmxPort, restart file, interactive mode and restart
loop in the end. Looks like the script can be significantly simplified,
will create a separate ticket for this as well.
вт, 27 авг. 2019 г. в 19:06, Alexey Goncharuk :
> Got to the bottom of the issue with empty output and no JAVA_HOME.
>
> The reason is the following line in bin/control.sh:
>
> javaMajorVersion "${JAVA_HOME}/bin/java"
>
> Since JAVA_HOME is empty, the argument passed to the function is invalid
> and terminates the script. I suggest to replace the "${JAVA_HOME}/bin/java"
> with just "$JAVA" because it is already determined earlier in the scope.
> The suggested fix works in my environment for all options of JAVA_HOME. I
> will create a ticket for 2.7.6 scope if there are no objections.
>
> Petr, do you have any idea how we can change the script to not fail
> silently and print at least some hint if it terminates early?
>
> вт, 27 авг. 2019 г. в 18:27, Sergey Antonov :
>
>> Hi everyone!
>>
>> Issue 3 fixed in master.
>> In master control.sh now is:
>> *> control.sh --help*
>>
>> Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
>> 2019 Copyright(C) Apache Software Foundation
>> User: santonov
>> Time: 2019-08-27T18:22:45.023
>> Control utility script is used to execute admin commands on cluster or get
>> common cluster info. The command has the following syntax:
>>
>> control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
>> [--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
>> PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
>> SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
>> SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
>> KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
>> KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
>> TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] [command]
>>
>>
>>
>> This utility can do the following commands:
>> Activate cluster:
>> control.(sh|bat) --activate
>>
>> Deactivate cluster:
>> control.(sh|bat) --deactivate [--yes]
>>
>> Print current cluster state:
>> control.(sh|bat) --state
>>
>> Print cluster baseline topology:
>> control.(sh|bat) --baseline
>>
>> Add nodes into baseline topology:
>> control.(sh|bat) --baseline add
>> consistentId1[,consistentId2,,consistentIdN] [--yes]
>>
>> Remove nodes from baseline topology:
>> control.(sh|bat) --baseline remove
>> consistentId1[,consistentId2,,consistentIdN] [--yes]
>>
>> Set baseline topology:
>> control.(sh|bat) --baseline set
>> consistentId1[,consistentId2,,consistentIdN] [--yes]
>>
>> Set baseline topology based on version:
>> control.(sh|bat) --baseline version topologyVersion [--yes]
>>
>> Set baseline autoadjustment settings:
>> control.(sh|bat) --baseline auto_adjust [disable|enable] [timeout
>> ] [--yes]
>>
>> List or kill transactions:
>> control.(sh|bat) --tx [--xid XID] [--min-duration SECONDS] [--min-size
>> SIZE] [--label PATTERN_REGEX] [--servers|--clients] [--nodes
>> consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER]
>> [--order
>> DURATION|SIZE|START_TIME] [--kill] [--info] [--yes]
>>
>> Print detailed information (topology and key lock ownership) about
>> specific transaction:
>> control.(sh|bat) --tx --info > [topVer=..., order=..., nodeOrder=...] (can be found in logs)>|> identifier as UUID (can be retrieved via --tx command)>
>>
>> View caches information in a cluster. For more details type:
>> control.(sh|bat) --cache help
>>
>> Print absolute paths of unused archived wal segments on each node:
>> control.(sh|bat) --wal print
>> [consistentId1,consistentId2,,consistentIdN]
>>
>> Delete unused archived wal segments on each node:
>> control.(sh|bat) --wal delete
>> [consistentId1,consistentId2,,consistentIdN] [--yes]
>>
>> View diagnostic information in a cluster. For more details type:
>> control.(sh|bat) --diagnostic
>>
>> Enable read-only mode on active cluster:
>> control.(sh|bat) --read-only-on [--yes]
>>
>> Disable read-only mode on active cluster:
>> control.(sh|bat) --read-only-off [--yes]
>>
>> By default commands affecting the cluster require interactive
>> confirmation.
>> Use --yes option to disable it.
>>
>> Default values:
>> HOST_OR_IP=127.0.0.1
>> PORT=11211
>> PING_INTERVAL=5000
>> PING_TIMEOUT=3
>> SSL_PROTOCOL=TLS
>> SSL_KEY_ALGORITHM=SunX509
>> KEYSTORE_TYPE=JKS
>> TRUSTSTORE_TYPE=JKS
>>
>> Exit codes:
>> 0 - successful execution.
>> 1 - invalid arguments.
>> 2 - connection failed.
>> 3 - authentication failed.
>> 4 - unexpected error.
>> Control utility has completed execution at: 20
Re: Control.sh usability & possible bugs
Got to the bottom of the issue with empty output and no JAVA_HOME.
The reason is the following line in bin/control.sh:
javaMajorVersion "${JAVA_HOME}/bin/java"
Since JAVA_HOME is empty, the argument passed to the function is invalid
and terminates the script. I suggest to replace the "${JAVA_HOME}/bin/java"
with just "$JAVA" because it is already determined earlier in the scope.
The suggested fix works in my environment for all options of JAVA_HOME. I
will create a ticket for 2.7.6 scope if there are no objections.
Petr, do you have any idea how we can change the script to not fail
silently and print at least some hint if it terminates early?
вт, 27 авг. 2019 г. в 18:27, Sergey Antonov :
> Hi everyone!
>
> Issue 3 fixed in master.
> In master control.sh now is:
> *> control.sh --help*
>
> Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
> 2019 Copyright(C) Apache Software Foundation
> User: santonov
> Time: 2019-08-27T18:22:45.023
> Control utility script is used to execute admin commands on cluster or get
> common cluster info. The command has the following syntax:
>
> control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
> [--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
> PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
> SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
> SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
> KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
> KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
> TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] [command]
>
>
>
> This utility can do the following commands:
> Activate cluster:
> control.(sh|bat) --activate
>
> Deactivate cluster:
> control.(sh|bat) --deactivate [--yes]
>
> Print current cluster state:
> control.(sh|bat) --state
>
> Print cluster baseline topology:
> control.(sh|bat) --baseline
>
> Add nodes into baseline topology:
> control.(sh|bat) --baseline add
> consistentId1[,consistentId2,,consistentIdN] [--yes]
>
> Remove nodes from baseline topology:
> control.(sh|bat) --baseline remove
> consistentId1[,consistentId2,,consistentIdN] [--yes]
>
> Set baseline topology:
> control.(sh|bat) --baseline set
> consistentId1[,consistentId2,,consistentIdN] [--yes]
>
> Set baseline topology based on version:
> control.(sh|bat) --baseline version topologyVersion [--yes]
>
> Set baseline autoadjustment settings:
> control.(sh|bat) --baseline auto_adjust [disable|enable] [timeout
> ] [--yes]
>
> List or kill transactions:
> control.(sh|bat) --tx [--xid XID] [--min-duration SECONDS] [--min-size
> SIZE] [--label PATTERN_REGEX] [--servers|--clients] [--nodes
> consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER] [--order
> DURATION|SIZE|START_TIME] [--kill] [--info] [--yes]
>
> Print detailed information (topology and key lock ownership) about
> specific transaction:
> control.(sh|bat) --tx --info [topVer=..., order=..., nodeOrder=...] (can be found in logs)>| identifier as UUID (can be retrieved via --tx command)>
>
> View caches information in a cluster. For more details type:
> control.(sh|bat) --cache help
>
> Print absolute paths of unused archived wal segments on each node:
> control.(sh|bat) --wal print
> [consistentId1,consistentId2,,consistentIdN]
>
> Delete unused archived wal segments on each node:
> control.(sh|bat) --wal delete
> [consistentId1,consistentId2,,consistentIdN] [--yes]
>
> View diagnostic information in a cluster. For more details type:
> control.(sh|bat) --diagnostic
>
> Enable read-only mode on active cluster:
> control.(sh|bat) --read-only-on [--yes]
>
> Disable read-only mode on active cluster:
> control.(sh|bat) --read-only-off [--yes]
>
> By default commands affecting the cluster require interactive confirmation.
> Use --yes option to disable it.
>
> Default values:
> HOST_OR_IP=127.0.0.1
> PORT=11211
> PING_INTERVAL=5000
> PING_TIMEOUT=3
> SSL_PROTOCOL=TLS
> SSL_KEY_ALGORITHM=SunX509
> KEYSTORE_TYPE=JKS
> TRUSTSTORE_TYPE=JKS
>
> Exit codes:
> 0 - successful execution.
> 1 - invalid arguments.
> 2 - connection failed.
> 3 - authentication failed.
> 4 - unexpected error.
> Control utility has completed execution at: 2019-08-27T18:22:45.193
> Execution time: 170 ms
>
> *> control.sh --cache help*
>
> Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
> 2019 Copyright(C) Apache Software Foundation
> User: santonov
> Time: 2019-08-27T18:25:01.577
> Command [CACHE] started
> Arguments: --cache help --yes
>
>
> The '--cache subcommand' is used to get information about and perform
> actions with caches. The command has the following syntax:
>
> control.(sh|bat) [--host HOST_OR_IP] [
Re: Control.sh usability & possible bugs
Hi everyone!
Issue 3 fixed in master.
In master control.sh now is:
*> control.sh --help*
Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
2019 Copyright(C) Apache Software Foundation
User: santonov
Time: 2019-08-27T18:22:45.023
Control utility script is used to execute admin commands on cluster or get
common cluster info. The command has the following syntax:
control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
[--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] [command]
This utility can do the following commands:
Activate cluster:
control.(sh|bat) --activate
Deactivate cluster:
control.(sh|bat) --deactivate [--yes]
Print current cluster state:
control.(sh|bat) --state
Print cluster baseline topology:
control.(sh|bat) --baseline
Add nodes into baseline topology:
control.(sh|bat) --baseline add
consistentId1[,consistentId2,,consistentIdN] [--yes]
Remove nodes from baseline topology:
control.(sh|bat) --baseline remove
consistentId1[,consistentId2,,consistentIdN] [--yes]
Set baseline topology:
control.(sh|bat) --baseline set
consistentId1[,consistentId2,,consistentIdN] [--yes]
Set baseline topology based on version:
control.(sh|bat) --baseline version topologyVersion [--yes]
Set baseline autoadjustment settings:
control.(sh|bat) --baseline auto_adjust [disable|enable] [timeout
] [--yes]
List or kill transactions:
control.(sh|bat) --tx [--xid XID] [--min-duration SECONDS] [--min-size
SIZE] [--label PATTERN_REGEX] [--servers|--clients] [--nodes
consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER] [--order
DURATION|SIZE|START_TIME] [--kill] [--info] [--yes]
Print detailed information (topology and key lock ownership) about
specific transaction:
control.(sh|bat) --tx --info |
View caches information in a cluster. For more details type:
control.(sh|bat) --cache help
Print absolute paths of unused archived wal segments on each node:
control.(sh|bat) --wal print
[consistentId1,consistentId2,,consistentIdN]
Delete unused archived wal segments on each node:
control.(sh|bat) --wal delete
[consistentId1,consistentId2,,consistentIdN] [--yes]
View diagnostic information in a cluster. For more details type:
control.(sh|bat) --diagnostic
Enable read-only mode on active cluster:
control.(sh|bat) --read-only-on [--yes]
Disable read-only mode on active cluster:
control.(sh|bat) --read-only-off [--yes]
By default commands affecting the cluster require interactive confirmation.
Use --yes option to disable it.
Default values:
HOST_OR_IP=127.0.0.1
PORT=11211
PING_INTERVAL=5000
PING_TIMEOUT=3
SSL_PROTOCOL=TLS
SSL_KEY_ALGORITHM=SunX509
KEYSTORE_TYPE=JKS
TRUSTSTORE_TYPE=JKS
Exit codes:
0 - successful execution.
1 - invalid arguments.
2 - connection failed.
3 - authentication failed.
4 - unexpected error.
Control utility has completed execution at: 2019-08-27T18:22:45.193
Execution time: 170 ms
*> control.sh --cache help*
Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
2019 Copyright(C) Apache Software Foundation
User: santonov
Time: 2019-08-27T18:25:01.577
Command [CACHE] started
Arguments: --cache help --yes
The '--cache subcommand' is used to get information about and perform
actions with caches. The command has the following syntax:
control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
[--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] --cache
[subcommand]
The subcommands that take [nodeId] as an argument ('list',
'find_garbage', 'contention' and 'validate_indexes') will be executed on
the given node or on all server nodes if the option is not specified. Other
commands will run on a random server node.
Subcommands:
--cache idle_verify [--dump] [--skip-zeros] [--check-crc]
[--exclude-caches cacheName1,...,cacheNameN] [--cache-filter
DEFAULT|SYSTEM|PERSISTENT|NOT_PERSISTENT|USER|ALL]
[cacheName1,...,cacheNameN]
Verify counters and hash sums of primary
Re: Control.sh usability & possible bugs
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 : > 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 : > > > 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] > > [] [--yes] > > > > > > Allowable : > > > --activate - ... > > > --deactivate - ... > > > ... > > > > > > -- > > > Best regards, > > > Anton Kalashnikov > > > > > > > > > 26.08.2019, 15:00, "Dmitriy Pavlov" : > > >> 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 > > >
Re: Control.sh usability & possible bugs
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 : > 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] > [] [--yes] > > > > Allowable : > > --activate - ... > > --deactivate - ... > > ... > > > > -- > > Best regards, > > Anton Kalashnikov > > > > > > 26.08.2019, 15:00, "Dmitriy Pavlov" : > >> 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 >
Re: Control.sh usability & possible bugs
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] [] [--yes] Allowable : --activate - ... --deactivate - ... ... -- Best regards, Anton Kalashnikov 26.08.2019, 15:00, "Dmitriy Pavlov" : 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
Re: Control.sh usability & possible bugs
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] [] [--yes] Allowable : --activate - ... --deactivate - ... ... -- Best regards, Anton Kalashnikov 26.08.2019, 15:00, "Dmitriy Pavlov" : > 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
Control.sh usability & possible bugs
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
