Closed kiootic closed 4 years ago
So, we'll have three commands?
It seems a bit inconsistent to me, since set-cluster would manipulate contexts implicitly, and there is no set-context. That is why I choose to expose clusters in the commands only.
The problem is that what skycli config set-cluster
is doing now is that it clears the config file and set up a context for the cluster.
skycli should always has a context to work with. A context is a combination of cluster and user. A context can without a user.
skycli config set-cluster
adds a new cluster. If the cluster already exists, it is an error. Otherwise create a new context with the new cluster. (Should we switch to the newly created context?)
skycli auth login
adds a new user. If the current context has no user, the context is updated in place. If the current context has user, create a new context with the cluster of the current context and the logged in user, switch to the new context.
skycli will have a global flag --context
to override current_context
in the config file.
Thoughts?
The issue described that we'll support only one user per cluster for now, i.e. only one context per cluster. Is that correct?
Anyways, set-cluster
need to be changed. I'm thinking of having set-cluster
always update the context and cluster with specified name according to the input parameters, so it's an upsert operation to clusters and contexts with cluster name as key.
I'll add the three commands mentioned before (get-contexts
, use-context
, set-cluster). Contexts can be added/updated through
set-cluster`, and logging in would affect the user of current context.
Thanks. Can you also introduce the global --context
flag? Actually it is original use case I want to support. It is particularly useful for skycli app get-k8s-credentials
.
Maybe we should also review whether we still keep skycli config view
Maybe we should also review whether we still keep skycli config view
I would suggest making skycli config view
output the config yaml verbatim.
ref #400