Support for contexts or profiles for remote gateways

[alexellis]

We could offer a way to support a profile or context as an alias for a gateway. A user suggested something similar about an "rc" file or not having to remember multiple gateway URLs in #479

Current behaviour

You need to remember your gateway URLs or look them up in ~/.openfaas/config.yaml

Feature

This might be similar to how kubectl handles multiple contexts.

# faas-cli create-context staging --gateway https://staging.openfaas.com

# faas-cli set-context staging
Using gateway: https://staging.openfaas.com

# faas-cli get-context staging
Using gateway: https://staging.openfaas.com

# faas-cli get-context

[x] staging
[ ] local
[ ] swarm

[jameschensmith]

I totally vouch for this enhancement (literally working with 20+ kube-contexts 😅), while also suggesting the potential of migrating the provider configuration to config.yml.

My main reasoning for this big of a change is influenced by the fact that I mainly work under private repositories, so the gateways that I use would most definitely not be included inside of the repository. I would instead use an alternative suggested here, using the --gateway flag or the OPENFAAS_URL environment variable.

I would guess that a large majority of the OpenFaaS function repositories have http://127.0.0.1:8080 or similar committed (examples), so I don't see much of an impact with regards to thinking of how to migrate users to this configuration (on an initial faas-cli command after new version, defaults could be cached right away to the configuration file).

[alexellis]

Wonder if there's much interest in this from our users?

[padiazg]

I think it would be useful, mainly to avoid deploying at the wrong gateway by mistake. Also for auditing and coordination purposes, as we work in teams using git as central repository. At creating a project the team leader could establish each context beforehand, improving project visibility.

[martindekov]

This remind me of setting OPENFAAS_URL without the search for the URL if properly written etc... I usually use --gateway for the times I need exception. I think that most of the people operate mainly with single OF instance at a time and rarely switch fast between instances. This is my take otherwise I can start digging in how to do this if no one is working on it ATM.

[alexellis]

I would like us to spend some more time working on the user experience before working on this with Go code.

cc @openfaas/cli @rgee0 @stefanprodan @LucasRoesler

[rgee0]

$ faas context create staging --gateway https://staging.openfaas.com`
Context 'staging' created using gateway: https://staging.openfaas.com

$ faas context set staging
Setting gateway: https://staging.openfaas.com

$ faas context get staging
Using gateway: https://staging.openfaas.com

$ faas context show
[x] staging
[ ] local
[ ] swarm

[LucasRoesler]

I like those. But I would prefer the verb use instead of set. Set makes me think it is an edit/update command. So,

$ faas context use staging

Also, we should support the hyphen shortcut

faas context use - # use previous ctx

We probably also want the ability to rename a context, like

$ faas context rename staging stg

[rgee0]

I considered use too, seems more intuitive. However, it gave me a sense of single use whereas set gives the user a sense of persistence.

I like the idea of - good for situations where the user wants to flip flop.

[johnmccabe]

@rgee0 I would avoid using pretty output on its own, as it makes scripting with the cli a pain.

$ faas context show
staging

Could alternately hang displaying the current context off the context root with no subcommand.

$ faas context
staging

I'd also stick to commonly used verbs across the cli, for example ls in place of show.

$ faas context ls
staging [active]
local
swam

It should also specify what output is returned when no context had been set and either some gateway logins exist, or nothing exists at all.

[rgee0]

I like the idea of utilising the root command of context. Take the point on show; I think we've used list elsewhere.

[johnmccabe]

You can alias both list and ls as we've done for the function list command.

https://github.com/openfaas/faas-cli/blob/7a861dbc0eba59251d6fc4e40c5aa42c8712bed0/commands/list.go#L29-L31

[LucasRoesler]

I like John's suggestion to keep the output scripting friendly and to use the root context command for the "show currently active".

If no context is active or none exist, it seems reasonable that it would return a message on standard error: "no context configured"