Config file parameter is ignored when submitting a job from the command line

[nfrankel]

Tried with both version 4.1 & 4.3.

Reproducer:

1. Configure a jettrain.yaml config file to a cluster that doesn't run on 127.0.0.1 e.g. remote, local Kubernetes, etc.

2. Get the state of the cluster

   ./jet -f ../config/jettrain.yaml cluster
   

   It correctly gets the data from the cluster

   State: ACTIVE
   Version: 4.3
   Size: 1
   
   ADDRESS                  UUID               
   [172.17.0.3]:5701        8381d229-4b09-4a2b-ae38-20b014fa60ee
   

3. Using the same config file on the command-line, it's ignored when I submit a job:

   ./jet -f ../config/jettrain.yaml submit ../../jet-train/load-static/target/load-static-1.0-SNAPSHOT.jar
   

   The output is:

   Submitting JAR '../../jet-train/load-static/target/load-static-1.0-SNAPSHOT.jar' with arguments []
   10:28:39.497 [ WARN] [c.h.c.i.c.ClientConnectionManager] hz.client_1 [jet] [4.3] [4.0.3] Exception during initial connection to [127.0.0.1]:5701: com.hazelcast.core.HazelcastException: java.net.SocketException: Connection refused to address /127.0.0.1:5701
   10:28:39.508 [ WARN] [c.h.c.i.c.ClientConnectionManager] hz.client_1 [jet] [4.3] [4.0.3] Exception during initial connection to [127.0.0.1]:5703: com.hazelcast.core.HazelcastException: java.net.SocketException: Connection refused to address /127.0.0.1:5703
   10:28:39.509 [ WARN] [c.h.c.i.c.ClientConnectionManager] hz.client_1 [jet] [4.3] [4.0.3] Exception during initial connection to [127.0.0.1]:5702: com.hazelcast.core.HazelcastException: java.net.SocketException: Connection refused to address /127.0.0.1:5702
   10:28:39.509 [ WARN] [c.h.c.i.c.ClientConnectionManager] hz.client_1 [jet] [4.3] [4.0.3] Unable to get live cluster connection, retry in 975 ms, attempt: 1 , cluster connect timeout: 1000 seconds , max backoff millis: 30000
   10:28:40.485 [ WARN] [c.h.c.i.c.ClientConnectionManager] hz.client_1 [jet] [4.3] [4.0.3] Exception during initial connection to [127.0.0.1]:5701: com.hazelcast.core.HazelcastException: java.net.SocketException: Connection refused to address /127.0.0.1:5701
   10:28:40.486 [ WARN] [c.h.c.i.c.ClientConnectionManager] hz.client_1 [jet] [4.3] [4.0.3] Exception during initial connection to [127.0.0.1]:5702: com.hazelcast.core.HazelcastException: java.net.SocketException: Connection refused to address /127.0.0.1:5702
   10:28:40.486 [ WARN] [c.h.c.i.c.ClientConnectionManager] hz.client_1 [jet] [4.3] [4.0.3] Exception during initial connection to [127.0.0.1]:5703: com.hazelcast.core.HazelcastException: java.net.SocketException: Connection refused to address /127.0.0.1:5703
   10:28:40.487 [ WARN] [c.h.c.i.c.ClientConnectionManager] hz.client_1 [jet] [4.3] [4.0.3] Unable to get live cluster connection, cluster connect timeout (1000 millis) is reached. Attempt 2.
   ERROR: Unable to connect to any cluster.
   

Though the configuration file is passed on the command-line, the command ignores it and uses the default configuration file.

[frant-hartm]

The job @nfrankel was submitting incorrectly used Jet.newJetClient() instead of Jet.bootstrappedInstance(). The -f option works as expected, but we should consider improving the documentation to make it clearer that the user should always use bootstrapped instance with jet submit.

[nfrankel]

The issue is due to the fact that the JAR was using Jet.newJetClient() instead of JetBootstrap.getInstance(). Thanks @frant-hartm for diagnosing the answer.

While not a defect, I think other users will get bitten by it. From the point of view of the command-line user, there's no way to understand why the file option is discarded. A message explicitly printing [WARN] Using newJetClient will use the default hazelcast-client.yaml file, ignoring xxx.yaml file passed to the command would be a tremendous help.

[cangencer]

Maybe Jet.newJetClient can act the same as Jet.newBootstrappedInstance when called within jet submit ?

[nfrankel]

@cangencer That option would be my preferred one as it follows the Principle of Least Surprise and is consistent.

Plus, as the caller of the command, I shouldn't be privy to the underlying code.