gateway url parameter priority not as described

[burtonr]

Using faas list in a directory where there is a stack.yml file, the gateway URL is always taken from the yml file. The --gateway parameter and the $OPENFAAS_URL values are not used as is described in the readme

Expected Behaviour

Expect the parameter to always be taken if it is provided as is described in the readme about priority.

Current Behaviour

If a stack.yml is present in the directory where the faas-cli is run, the values in that file will always take precedence

Possible Solution

Adjust the getGatewayURL func to return as soon as it finds a match following the priority listed in the readme OR update the readme to indicate that the stack.yml file values, if present, override all other options

Steps to Reproduce (for bugs)

1. Create stack.yml file
2. Edit the gateway field to something else
3. Run faas list, or other command that connects to the gateway
4. Observe that the command cannot connect and is pointed to the value in the stack.yml
5. Pass the -g flag to the same command and observe that the value from the stack.yml is still used

Context

Troubleshooting why the cli could not connect to a new cluster when using a directory where previous functions had been developed prior.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):

$ faas version
CLI:
 commit:  a141dedf94ffeed84412365fd591bdc8999c5a1b
 version: 0.8.3

• Docker version ( Full output from: docker version ):

$ docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:25:03 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:23:27 2018
  OS/Arch:          linux/amd64
  Experimental:     false

• Are you using Docker Swarm (FaaS-swarm ) or Kubernetes (FaaS-netes)? Swarm
• Operating System and version (e.g. Linux, Windows, MacOS): Linux Pop!_os 18.06
• Link to your project or a code example to reproduce issue: N/A

[alexellis]

Thanks for logging your findings @burtonr - I'll merge as priority/low since I don't think we have any other reports in "recent memory" so I'm not sure it's a pressing problem for the majority of users.

Looking into the code I see we have tests for this and the value in the YAML file is considered in the getGatewayURL code:

https://github.com/openfaas/faas-cli/blob/d33cb5cdc128b75fc7a9856c30fc0eded39fec1e/commands/config_priority_test.go

https://github.com/openfaas/faas-cli/blob/d52f47461872966966d9419f4f5e2a5bd13928f0/commands/list.go#L51

[rgee0]

I think the missing detail here is what is being passed in through -g. If its the same as the defaultGateway then it wont take precedence. This is me trying to reproduce:

$ faas list -g http://127.0.0.1:8080
Cannot connect to OpenFaaS on URL: http://122.1.1.1:8080

$ faas list -g http://127.0.1.1:8080
Cannot connect to OpenFaaS on URL: http://127.0.1.1:8080

$ ls
function-name	stack.yml	template
$ cat stack.yml | grep gate
  gateway: http://122.1.1.1:8080

The first command ignores the gateway flag as it matches the default and the stack.yml is used instead. The second command uses the gateway flag, even though i haven't moved dir.

[mario-mazo]

If approved I would like to work on this

[rgee0]

Im not sure what, if anything there is to work on. I think my comment above shoves that -g is honoured even when a stack.yml is present provided the -g value doesn't correspond with the defaultGateway value, which I think is the intended behaviour.

Maybe @burtonr can provide further detail.

[burtonr]

If there is a "fix", it would be to the documentation on the gateway URL override in the readme.

It needs to be explained that there are a couple of catches to watch out for. Specifically:

• If present, the stack.yml file's defined gateway URL is used
• Cannot override to the default URL 127.0.0.1:8080

Neither of those are documented which is what prompted this issue.

[npoirey]

This issue is old but I just encountered it and couldn't undersand why it wasn't taken into account. My OPENFAAS_URL is my staging url but I wanted to try something locally and -g with http://127.0.0.1:8080 was not taken into account. I replaced it with http://localhost:8080 and it works.

I find it unusual and unexpected to ignore a flag if the value passed is equal to some arbitrary value so my personal opinion would be to rework the behavior, but at the very least documentation should reflect this special case.