Repository: vespa-engine/vespa (language: java)

Issue:
Vespa deploy CLI command with --wait does not work as expected in a self-hosted multi-node environment
**Is your feature request related to a problem? Please describe.**
Just had a chat on slack about the following problem:
Hey Team, we're now running our vespa cluster on the following setup (for now):
* on one machine (leader): config-server, cluster-controller, slobroks, adminserver
* on two other machines (searchers): content, containers

Now we would like to run the `vespa deploy --wait 300` cli on the leader nodes, but the result is the following:

```Waiting up to 5m0s for deploy API...
Success: Deployed '.' with session ID 2
Waiting up to 5m0s for deployment to converge...
Waiting up to 5m0s for cluster discovery...
Waiting up to 5m0s for container default...
Error: unhealthy container default after waiting up to 5m0s at http://127.0.0.1:8080/status.html: Get "http://127.0.0.1:8080/status.html": dial tcp 127.0.0.1:8080: connect: connection refused
```
I think that the deployment of the application files went fine, because they can be uploaded to localhost (where the config-server is), but the check afterwards in the vespa-deploy doesn't makes sense to me, because on the config-server shouldn't be any content/container node on port 8080.
Do we something completely wrong in our setup? Because I would expect that for the _"Waiting... for container default"_ I would need to define a different target url than the usual deploy.
########

Jo wrote that multiple people had problems with this implicit behaviour (if you add --wait to the deploy command, the command does not exit correctly).

**Describe the solution you'd like**
Multiple options:
* Let me define another container-target url as parameter
* Give me the option to configure my environment via `vespa config ...`
* Proper exception
* Minimum: Highlight this behaviour in the documentation
* ...

**Describe alternatives you've considered**
-

**Additional context**
-



Discussion / hints:
Yes, this does not work as expected for multi-node setup. However, you should be able to use `vespa status deployment --wait 600`.
That is, `vespa deploy` without `--wait` and then `vespa status deployment --wait 600` to wait for completion.

Fix patch:
diff --git a/client/go/internal/cli/cmd/deploy.go b/client/go/internal/cli/cmd/deploy.go
index 4792088a915a..d3bda1089a7b 100644
--- a/client/go/internal/cli/cmd/deploy.go
+++ b/client/go/internal/cli/cmd/deploy.go
@@ -185,8 +185,10 @@ func waitForVespaReady(target vespa.Target, sessionOrRunID int64, waiter *Waiter
 		if _, err := waiter.Deployment(target, sessionOrRunID); err != nil {
 			return err
 		}
-		// Wait for healthy services
-		if hasTimeout {
+		// Wait for healthy services where we expect them to be reachable (cloud and local). When using a custom target,
+		// we do not wait for services as there is no guarantee that they are reachable from the machine executing
+		// deploy.
+		if hasTimeout && (target.IsCloud() || target.Type() == vespa.TargetLocal) {
 			_, err := waiter.Services(target)
 			return err
 		}


Test patch: