CLI can't successfully deploy to 'custom' named stack

[0xdevalias]

Expected Behaviour

When I deploy a command to my custom named stack, it works (or gives me an error saying it can't)

Current Behaviour

The CLI claims to successfully deploy the command, but it doesn't work. There is an error in the logs of the gateway. The CLI appears to have hardcoded the name:

⇒  docker service logs openfaas_gateway
..snip..
openfaas_gateway.1.5v3xwo4u9mvb@moby    | 2017/09/14 00:19:43 Error response from daemon: network func_functions not found

https://github.com/alexellis/faas-cli/blob/3a2e81471c69275571d71f84c158bb787fb1ad7b/proxy/deploy.go#L44

There also seems to be a defaultNetwork defined that may not be used anywhere yet:

https://github.com/alexellis/faas-cli/blob/fa5668b52afea6fc90434d67cfe211572da03cbd/commands/faas.go#L12

Possible Solution

Allow the network to be specified in the CLI. Return a proper error when deploys fail. Investigate whether the gateway can determine the correct network itself, without relying on the CLI telling it.

Steps to Reproduce (for bugs)

1. Create a new network stack, change the stack name and network name
2. Try and deploy an image with the CLI
3. Check the gateway logs

Context

Your Environment

⇒  docker --version
Docker version 17.06.2-ce, build cec0b72

⇒  faas-cli version
Git Commit: 118e3e904aa930cafdb64f0efd4538c76fb27088

[alexellis]

Can you jump in on this?

[0xdevalias]

@alexellis Theoretically maybe, but in reality I have so much going on in so many different things right now that I am hesitant to commit to anything new. If/when i find spare time/energy to actually contribute something code-wise, I will, but I don't know if/when that will be.

[alexellis]

This will be fixed in #100 - please can you pull the code from master and build to confirm @alias1?

[alexellis]

Closing via #100 - if there are issues when testing please ping @itscaro and re-open.

[0xdevalias]

Hopefully able to check this out later, not setup to build/run faas-cli from the repo atm.

In the meantime, I see that it was released as 0.4.14

Tried bumping in homebrew (similar to previous updates), but hangs here. Maybe @johnmccabe has a better idea?

⇒  brew bump-formula-pr --tag=0.4.14 --revision=a2c488e389dade9dc4f609dda87f15c8e74e79ec faas-cli
Already up-to-date.
==> replace "0.4.12" with "0.4.14"
==> replace "118e3e904aa930cafdb64f0efd4538c76fb27088" with "a2c488e389dade9dc4f609dda87f15c8e74e79ec"
remote: Counting objects: 299986, done.
remote: Compressing objects: 100% (131337/131337), done.
^Cceiving objects:  36% (109166/299986), 33.37 MiB | 2.62 MiB/s

Edit: Done by @ilovezfs :3

[0xdevalias]

@itscaro So testing the default 'fail case', openfaas/cli still report the deploy as sucessful, even though it isn't. Did a little digging on slack as to where this seems to be coming from the other day, can't remember where it was off hand (in the gateway+CLI from memory). But basically, I would expect that the error shown in the logs should be returned somehow to fail the deploy command, or provide some more useful feedback there. Can we reopen to track that aspect?

⇒  faas-cli deploy -f functions.yml
Deploying: gobuster.
No existing service to remove
Deployed.
200 OK
URL: http://localhost:8080/function/gobuster

⇒  docker service ls
ID                  NAME                    MODE                REPLICAS            IMAGE                           PORTS
ewmlw9ps7np7        openfaas_prometheus     replicated          1/1                 functions/prometheus:latest     *:9090->9090/tcp
niwv0uts5pmw        openfaas_alertmanager   replicated          1/1                 functions/alertmanager:latest   *:9093->9093/tcp
tbwsinh7sqok        openfaas_gateway        replicated          1/1                 functions/gateway:0.6.3         *:8080->8080/tcp

⇒  docker service logs openfaas_gateway
openfaas_gateway.1.1w7br0vud8mj@moby    | 2017/09/18 21:41:41 HTTP Read Timeout: 8s
openfaas_gateway.1.1w7br0vud8mj@moby    | 2017/09/18 21:41:41 HTTP Write Timeout: 8s
openfaas_gateway.1.1w7br0vud8mj@moby    | 2017/09/18 21:41:41 Docker API version: 1.30, 17.06.0-ce
openfaas_gateway.1.1w7br0vud8mj@moby    | 2017/09/18 21:44:15 Attempting to remove service gobuster
openfaas_gateway.1.1w7br0vud8mj@moby    | 2017/09/18 21:44:15 0
openfaas_gateway.1.1w7br0vud8mj@moby    | {gobuster devalias/gobuster-faas func_functions  map[] }
openfaas_gateway.1.1w7br0vud8mj@moby    | 2017/09/18 21:44:16 Error response from daemon: network func_functions not found
openfaas_gateway.1.1w7br0vud8mj@moby    | 2017/09/18 21:44:16  []

As for testing the new changes, it looks like it works correctly.

⇒  faas-cli deploy --network openfaas_openfaas -f functions.yml
Deploying: gobuster.
No existing service to remove
Deployed.
200 OK
URL: http://localhost:8080/function/gobuster

⇒  docker service ls
ID                  NAME                    MODE                REPLICAS            IMAGE                           PORTS
bmjnb2d3nb6r        gobuster                replicated          1/1                 devalias/gobuster-faas
ewmlw9ps7np7        openfaas_prometheus     replicated          1/1                 functions/prometheus:latest     *:9090->9090/tcp
niwv0uts5pmw        openfaas_alertmanager   replicated          1/1                 functions/alertmanager:latest   *:9093->9093/tcp
tbwsinh7sqok        openfaas_gateway        replicated          1/1                 functions/gateway:0.6.3         *:8080->8080/tcp

Including it the network in my functions.yml also seems to work correctly now.

provider:
  name: faas
  gateway: http://localhost:8080
  network: openfaas_openfaas

⇒  faas-cli deploy -f functions.yml
Deploying: gobuster.
Removing old service.
Deployed.
200 OK
URL: http://localhost:8080/function/gobuster

Not sure if this additional key in the functions.yml is documented anywhere, but if not, would be good to. Only noticed it through reading the code.

[itscaro]

@alias1, @alexellis should it be a new issue in faas to make the gateway return the error to faas-cli?

[alexellis]

There is technically no error, just unexpected behaviour. The service responded 200 because it was a valid request and accepted by the scheduler. Maybe we can update the documentation to make this clearer.

[0xdevalias]

Hrmm.. i'm not sure if I would agree that there is 'no error', but I suppose that depends on how you're defining it.

The log line specifically states error:

openfaas_gateway.1.1w7br0vud8mj@moby    | 2017/09/18 21:44:16 Error response from daemon: network func_functions not found

If faas-cli is treating a 200/no error as "i sent a command and the server got it" then i'd agree there is no error, but from a UX perspective.. that's going to be super confusing and unintuitive to most.

I'm not sure how quickly the gateway returns a 200 without digging deeper, but from a 'logical' perspective, I would expect if it's able to log an error, it should be able to return an error response, that faas-cli could then pick up on/report as appropriate. Even if the solution was "something weird happened go look at the gateway logs".

@itscaro It probably makes sense to raise it as an issue there. I'll go open something when I have a spare minute to figure it out what to include.

[alexellis]

I didn't see that there was an error logged, in which case we can change the http code and response message. It's a quick fix.

https://github.com/alexellis/faas/blob/master/gateway/handlers/createhandler.go#L57

[0xdevalias]

Opened faas issue for it: openfaas/faas#195

@itscaro Also, related to this issue. Using the command line flag with the yaml file, the yaml file seems to take precedence. Do we have a defined 'order of operations' across faas-cli? I would normally expect a command line argument to overwrite a 'settings file'.

So in the following example, it would appear to deploy to openfaas_openfaas, rather than foo_bar:

⇒  head -n 4 functions.yml
provider:
  name: faas
  gateway: http://localhost:8080
  network: openfaas_openfaas

⇒  faas-cli deploy --network foo_bar -f functions.yml
Deploying: gobuster.
Removing old service.
Deployed.
200 OK
URL: http://localhost:8080/function/gobuster