Open burtonr opened 5 years ago
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:
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.
If approved I would like to work on this
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.
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:
stack.yml
file's defined gateway URL is used127.0.0.1:8080
Neither of those are documented which is what prompted this issue.
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.
Using
faas list
in a directory where there is astack.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 readmeExpected 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 thefaas-cli
is run, the values in that file will always take precedencePossible 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 thestack.yml
file values, if present, override all other optionsSteps to Reproduce (for bugs)
stack.yml
filegateway
field to something elsefaas list
, or other command that connects to the gatewaystack.yml
-g
flag to the same command and observe that the value from thestack.yml
is still usedContext
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
):docker version
):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