Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chectl should use current namespace if no namespace is specified #16958

Closed
l0rd opened this issue May 16, 2020 · 5 comments
Closed

chectl should use current namespace if no namespace is specified #16958

l0rd opened this issue May 16, 2020 · 5 comments
Labels
area/chectl Issues related to chectl, the CLI of Che kind/enhancement A feature request - must adhere to the feature request template. severity/P2 Has a minor but important impact to the usage or development of the system.
Milestone

Comments

@l0rd
Copy link
Contributor

l0rd commented May 16, 2020

Currently, if the users doesn't specifies a namespace, chectl deploys che in the default namespace (che). For consistency with other command line tools the current user namespace should be used instead. That is true for chectl server:delete as well: if no namespace is specified the current one should be considered, not the default (che).

@l0rd l0rd added kind/enhancement A feature request - must adhere to the feature request template. area/chectl Issues related to chectl, the CLI of Che labels May 16, 2020
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label May 16, 2020
@sleshchenko
Copy link
Member

I would like to see user's confirmation you're going install Che on cluster XXX in namespace XXX. Press Y to continue before proceeding to install into the current namespace.
@l0rd Do you think such confirmation would be useful or redundant?

@l0rd
Copy link
Contributor Author

l0rd commented May 18, 2020

Ok but for consistency it should be interactive in every case then (even when flag --namespace is provided). And there should be another flag (--batch) for non interactive mode.

@sleshchenko sleshchenko added severity/P2 Has a minor but important impact to the usage or development of the system. and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels May 18, 2020
@tolusha tolusha added this to the Backlog - Deploy milestone May 28, 2020
@tolusha tolusha mentioned this issue Jun 1, 2020
34 tasks
@tolusha tolusha modified the milestones: Backlog - Deploy, 7.15 Jun 3, 2020
@mmorhun mmorhun mentioned this issue Jun 23, 2020
14 tasks
@tolusha tolusha modified the milestones: 7.15, 7.16 Jun 30, 2020
@tolusha
Copy link
Contributor

tolusha commented Jul 1, 2020

The priority of choosing the namespace is the following:

  1. use the namespace from the --chenamespace flag
  2. use the namespace defined in the current context
  3. use the default namespace name

Additional context https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#working-with-namespaces

@tolusha
Copy link
Contributor

tolusha commented Jul 3, 2020

@l0rd
I have some concerns. Changing the default behavior will cause issues.
I believe many bash scripts rely on the fact that che is the default namespace.
Is it better just to mention in the doc that it is necessary to update the current context [1] to have access to Eclipse Che namespace by default?

[1] kubectl config set-context --current --namespace=che

@l0rd
Copy link
Contributor Author

l0rd commented Jul 6, 2020

@tolusha yeah I was thinking that this issue won't be relevant as soon as #17187 will be implemented so...closing the issue.

@l0rd l0rd closed this as completed Jul 6, 2020
@tolusha tolusha mentioned this issue Jul 13, 2020
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/chectl Issues related to chectl, the CLI of Che kind/enhancement A feature request - must adhere to the feature request template. severity/P2 Has a minor but important impact to the usage or development of the system.
Projects
None yet
Development

No branches or pull requests

4 participants