Kubectl namespace support #1941

derekwaynecarr · 2014-10-21T22:31:12Z

Added support for setting a namespace for kubectl requests.

smarterclayton · 2014-10-22T03:44:56Z

Tests?

derekwaynecarr · 2014-10-22T14:16:30Z

Added test for getting namespace information from disk.

ghodss · 2014-10-22T17:58:40Z

Instead of a separate subcommand and file on disk for this info, I think this shows we are overdue for a kubectl config command. See #1755 (comment) for more info and imagine using kubectl config namespace myns to change the current namespace.

smarterclayton · 2014-10-22T18:53:03Z

I don't know that I consider 'git config' to be the right experience here. If you're switching contexts, that's not just a single config flag, it's a whole stack of behaviors. Swapping between those is a contextual action - how does config make it better?

----- Original Message -----

Instead of a separate subcommand and file on disk for this info, I think this
shows we are overdue for a kubectl config command. See
#1755 (comment)
for more info and imagine using kubectl config namespace myns to change
the current namespace.

Reply to this email directly or view it on GitHub:
#1941 (comment)

ghodss · 2014-10-22T19:15:59Z

Maybe we need a kubectl namespace command, but I still think the storage of the information should ultimately not be on its own and instead should be bundled and managed with the rest of any kubectl config.

If we implement #1755, then when I'm using kubectl, I've likely done some command like kubectl use timsgce (instead of setting the env var like we do today). At this point the kubectl namespace <ns> command would change the param in the timsgce config I have on disk. If I run kubectl namespace <ns> when I am not in a cluster context, I would expect it to do something like set my global default namespace to <ns>.

This all needs to be designed and implemented, so this PR is probably good for now, but I would just expect the internal behavior (and possibly some of the external behavior) to change when we sort out all the config stuff.

ghodss · 2014-10-22T19:18:11Z

pkg/kubectl/cmd/namespace.go

+  Using namespace default
+
+  $ kubectl namespace other
+  Using namespace other`,


It would be nice if there was some slightly different language for when the namespace is set vs is just being displayed. Since "default" is the namespace used when none is provided, it's not entirely clear that kubectl namespace Using namespace default isn't actually also setting it to default/clearing the value.

Good point. I will make an update.

Sent from my iPhone

On Oct 22, 2014, at 3:18 PM, Sam Ghods notifications@github.com wrote:

In pkg/kubectl/cmd/namespace.go:

+)
+
+func NewCmdNamespace(out io.Writer) *cobra.Command {

cmd := &cobra.Command{

Use: "namespace [<namespace>]",

Short: "Set and view the current Kubernetes namespace",

Long: `Set and view the current Kubernetes namespace scope for command line requests.

+A Kubernetes namespace subdivides the cluster into groups of logically related pods, services, and replication controllers.
+
+Examples:

$ kubectl namespace

Using namespace default

$ kubectl namespace other

Using namespace other`,
It would be nice if there was some slightly different language for when the namespace is set vs is just being displayed. Since "default" is the namespace used when none is provided, it's not entirely clear that kubectl namespace Using namespace default isn't actually also setting it to default/clearing the value.

—
Reply to this email directly or view it on GitHub.

Did this get addressed?

derekwaynecarr · 2014-10-22T19:21:38Z

Completely agree on need to consolidate on disk storage when that command is available.

Sent from my iPhone

On Oct 22, 2014, at 3:16 PM, Sam Ghods notifications@github.com wrote:

Maybe we need a kubectl namespace command, but I still think the storage of the information should ultimately not be on its own and instead should be bundled and managed with the rest of any kubectl config.

If we implement #1755, then when I'm using kubectl, I've likely done some command like kubectl use timsgce (instead of setting the env var like we do today). At this point the kubectl namespace command would change the param in the timsgce config I have on disk. If I run kubectl namespace when I am not in a cluster context, I would expect it to do something like set my global default namespace to .

This all needs to be designed and implemented, so this PR is probably good for now, but I would just expect the internal behavior (and possibly some of the external behavior) to change when we sort out all the config stuff.

—
Reply to this email directly or view it on GitHub.

smarterclayton · 2014-10-22T23:24:07Z

That I agree with - like Git, there are certain config levels that make sense (global, user, repo) but unlike Git one config repository needs to handle multiple repositories of config (namespaces).

Perhaps global config, per-server config, and per-namespace config are all relevant, with user config being less relevant.

On Oct 22, 2014, at 3:16 PM, Sam Ghods notifications@github.com wrote:

Maybe we need a kubectl namespace command, but I still think the storage of the information should ultimately not be on its own and instead should be bundled and managed with the rest of any kubectl config.

If we implement #1755, then when I'm using kubectl, I've likely done some command like kubectl use timsgce (instead of setting the env var like we do today). At this point the kubectl namespace command would change the param in the timsgce config I have on disk. If I run kubectl namespace when I am not in a cluster context, I would expect it to do something like set my global default namespace to .

This all needs to be designed and implemented, so this PR is probably good for now, but I would just expect the internal behavior (and possibly some of the external behavior) to change when we sort out all the config stuff.

—
Reply to this email directly or view it on GitHub.

derekwaynecarr · 2014-10-23T21:51:04Z

Differentiated message on set namespace versus viewing the current.
Rebased to latest.

thockin · 2014-10-24T05:13:48Z

pkg/kubectl/modify.go

@@ -63,11 +63,11 @@ func Modify(w io.Writer, c *client.RESTClient, action ModifyAction, data []byte)
 	var id string
 	switch action {
 	case "create":
-		id, err = doCreate(c, resource, data)
+		id, err = doCreate(c, namespace, resource, data)


What happens if the data already has "namespace" set? Who wins? I am not so enthused about special-casing this one field, except in cases like GET where there is no input already. Allowing people (encouraging really) to rely on the environmental definition of namespace feels sketchy to me.

If the data already has a namespace set, and you post to a URL for an alternate namespace, the server properly rejects the request and states that the namespace in the data does not match the namespace of the request.

thockin · 2014-10-24T05:18:53Z

I very much like the idea of "kubectl config", but I agree that it needs some real design work. I'm wary of this PR, partly because we haven't done that design work.

derekwaynecarr · 2014-10-24T15:12:24Z

@thockin - see my previous comment if that is related to your wariness, but this is bringing the same ability we delivered to kubecfg and had specified in the namespaces.md design document. Even in the presence of kubectl config, I think we will want this command.

derekwaynecarr · 2014-10-24T15:18:16Z

Rebased

bgrant0607 · 2014-10-27T23:11:02Z

Sorry for not paying attention. What do we expect to be in NamespaceInfo soon? Right now, it's just namespace, in which case this is overkill and we should just accept namespace from environment variable and command-line flag.

smarterclayton · 2014-10-27T23:44:11Z

I'll make the case that namespace (and context) is as or more important to get right in client tools. The pattern we're building off of is ensuring the user makes an explicit choice to set a default context instead of requiring it on every call. It's not absolutely required to deliver this, but in practice i feel this is the bare minimum to make an acceptable user experience for end users who approach the tools day to day.

The problem with environment only is that it can lead to unexpected and ambiguous behavior - forget to set an env and you can destroy a production cluster. To me, namespace is as important as the current directory is to git in terms of clearly communicating scope. Unfortunately the shell handles that scope for Git by default (the prompt is a powerful additional tool, as evidenced by common git to shell integration, that env could also be integrated with).

Derek and I can make a more structured argument in detail for this.

On Oct 27, 2014, at 7:11 PM, bgrant0607 notifications@github.com wrote:

Sorry for not paying attention. What do we expect to be in NamespaceInfo soon? Right now, it's just namespace, in which case this is overkill and we should just accept namespace from environment variable and command-line flag.

—
Reply to this email directly or view it on GitHub.

derekwaynecarr · 2014-10-27T23:56:49Z

I guess I thought the CLI for namespaces was the least controversial aspect of the overall proposal. I echo what Clayton said, but I will elaborate that NamespaceInfo is not expected to grow, but we anticipate it moving into a central style config file similar to git-config. @erictune any input here? I think our perspective is different in that we anticipate rarely operating in the "default" namespace, and it will be the norm for our end users to switch namespace contexts. Given this an environment variable is really annoying in the same way specifying a -b argument to every git operation would be a pain if you were not on master.

Sent from my iPhone

On Oct 27, 2014, at 7:44 PM, Clayton Coleman notifications@github.com wrote:

I'll make the case that namespace (and context) is as or more important to get right in client tools. The pattern we're building off of is ensuring the user makes an explicit choice to set a default context instead of requiring it on every call. It's not absolutely required to deliver this, but in practice i feel this is the bare minimum to make an acceptable user experience for end users who approach the tools day to day.

The problem with environment only is that it can lead to unexpected and ambiguous behavior - forget to set an env and you can destroy a production cluster. To me, namespace is as important as the current directory is to git in terms of clearly communicating scope. Unfortunately the shell handles that scope for Git by default (the prompt is a powerful additional tool, as evidenced by common git to shell integration, that env could also be integrated with).

Derek and I can make a more structured argument in detail for this.

On Oct 27, 2014, at 7:11 PM, bgrant0607 notifications@github.com wrote:

Sorry for not paying attention. What do we expect to be in NamespaceInfo soon? Right now, it's just namespace, in which case this is overkill and we should just accept namespace from environment variable and command-line flag.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

bgrant0607 · 2014-10-28T04:29:38Z

Which is considered more important at this point, making it possible to specify the namespace or getting the CLI config mechanism in place? Would you like this PR to be reviewed for one, the other, or both of these issues?

bgrant0607 · 2014-10-28T04:34:02Z

I will comment further on config in #1755.

derekwaynecarr · 2014-10-28T14:36:34Z

@bgrant0607, I would like this PR reviewed as a mechanism to specify the namespace and not the general purpose CLI config mechanism. I think the operation as specified can remain unchanged, and the general purpose CLI config mechanism can move the persistence of the information to a centralized location at the same time it moves persistence of the authentication info. We have downstream use cases where this is important to us in the near term.

derekwaynecarr · 2014-10-28T14:58:42Z

Just a reminder, this is migrating a feature that is in kubecfg today, but was not completed when kubectl was initially integrated. I need to get kubectl functionally equivalent.

On Oct 28, 2014, at 12:34 AM, bgrant0607 notifications@github.com wrote:

I will comment further on config in #1755.

—
Reply to this email directly or view it on GitHub.

bgrant0607 · 2014-10-29T02:45:45Z

Ok, this is fine by me pending the one point about distinguishing getting vs. setting in output.

We can defer the config overhaul of all similar persistent flags to #1755.

derekwaynecarr · 2014-10-29T14:22:32Z

The update to distinguish between setting and viewing current namespace has been made.

$ cluster/kubectl.sh namespace
Using namespace default
$ cluster/kubectl.sh namespace other
Set current namespace to other

Thanks all.

bgrant0607 · 2014-10-29T19:17:09Z

LGTM

bgrant0607 · 2014-10-29T19:17:24Z

Pls. squash commits

Add unit test for load namespace info Different message on display of namespace versus setting namespace

derekwaynecarr · 2014-10-30T15:09:17Z

@bgrant0607 squashed.

Kubectl namespace support

bgrant0607 · 2015-01-22T19:02:05Z

@derekwaynecarr Would you be willing to update namespaces.md to refer to kubectl rather than kubecfg?

derekwaynecarr · 2015-01-24T13:23:37Z

Sure, no problem.

Sent from my iPhone

On Jan 22, 2015, at 2:02 PM, Brian Grant notifications@github.com wrote:

@derekwaynecarr Would you be willing to update namespaces.md to refer to kubectl rather than kubecfg?

—
Reply to this email directly or view it on GitHub.

CFE-910: bump library-go

derekwaynecarr force-pushed the kubectl_ns branch from 6abdb46 to 2781dbb Compare October 22, 2014 14:17

ghodss reviewed Oct 22, 2014
View reviewed changes

derekwaynecarr force-pushed the kubectl_ns branch from d659f25 to a6a3632 Compare October 23, 2014 21:50

thockin reviewed Oct 24, 2014
View reviewed changes

derekwaynecarr force-pushed the kubectl_ns branch from a6a3632 to d86e9fa Compare October 24, 2014 15:18

bgrant0607 added the area/kubectl label Oct 27, 2014

bgrant0607 self-assigned this Oct 27, 2014

bgrant0607 mentioned this pull request Oct 28, 2014

Support multiple CLI configuration profiles #1755

Closed

derekwaynecarr force-pushed the kubectl_ns branch from d86e9fa to 88277b5 Compare October 29, 2014 14:12

Kubectl namespace support

5a7aced

Add unit test for load namespace info Different message on display of namespace versus setting namespace

derekwaynecarr force-pushed the kubectl_ns branch from 88277b5 to 5a7aced Compare October 30, 2014 15:06

bgrant0607 added a commit that referenced this pull request Oct 30, 2014

Merge pull request #1941 from derekwaynecarr/kubectl_ns

1007743

Kubectl namespace support

bgrant0607 merged commit 1007743 into kubernetes:master Oct 30, 2014

derekwaynecarr mentioned this pull request Nov 3, 2014

[WIP] [DO_NOT_MERGE]: introducing osc (end-user CLI) openshift/origin#112

Closed

deads2k mentioned this pull request Nov 4, 2014

rebase kubernetes for demo openshift/origin#330

Merged

derekwaynecarr mentioned this pull request Nov 4, 2014

WIP: kubectl support for origin resources fabianofranz/origin#1

Open

derekwaynecarr deleted the kubectl_ns branch April 17, 2015 17:56

deads2k pushed a commit to deads2k/kubernetes that referenced this pull request Apr 16, 2024

Merge pull request kubernetes#1941 from sanchezl/bump

5fa1806

CFE-910: bump library-go

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Kubectl namespace support #1941

Kubectl namespace support #1941

derekwaynecarr commented Oct 21, 2014

smarterclayton commented Oct 22, 2014

derekwaynecarr commented Oct 22, 2014

ghodss commented Oct 22, 2014

smarterclayton commented Oct 22, 2014

ghodss commented Oct 22, 2014

ghodss Oct 22, 2014

derekwaynecarr Oct 22, 2014

bgrant0607 Oct 29, 2014

derekwaynecarr commented Oct 22, 2014

smarterclayton commented Oct 22, 2014

derekwaynecarr commented Oct 23, 2014

thockin Oct 24, 2014

derekwaynecarr Oct 24, 2014

thockin commented Oct 24, 2014

derekwaynecarr commented Oct 24, 2014

derekwaynecarr commented Oct 24, 2014

bgrant0607 commented Oct 27, 2014

smarterclayton commented Oct 27, 2014

derekwaynecarr commented Oct 27, 2014

bgrant0607 commented Oct 28, 2014

bgrant0607 commented Oct 28, 2014

derekwaynecarr commented Oct 28, 2014

derekwaynecarr commented Oct 28, 2014

bgrant0607 commented Oct 29, 2014

derekwaynecarr commented Oct 29, 2014

bgrant0607 commented Oct 29, 2014

bgrant0607 commented Oct 29, 2014

derekwaynecarr commented Oct 30, 2014

bgrant0607 commented Jan 22, 2015

derekwaynecarr commented Jan 24, 2015

Kubectl namespace support #1941

Kubectl namespace support #1941

Conversation

derekwaynecarr commented Oct 21, 2014

smarterclayton commented Oct 22, 2014

derekwaynecarr commented Oct 22, 2014

ghodss commented Oct 22, 2014

smarterclayton commented Oct 22, 2014

ghodss commented Oct 22, 2014

ghodss Oct 22, 2014

Choose a reason for hiding this comment

derekwaynecarr Oct 22, 2014

Choose a reason for hiding this comment

bgrant0607 Oct 29, 2014

Choose a reason for hiding this comment

derekwaynecarr commented Oct 22, 2014

smarterclayton commented Oct 22, 2014

derekwaynecarr commented Oct 23, 2014

thockin Oct 24, 2014

Choose a reason for hiding this comment

derekwaynecarr Oct 24, 2014

Choose a reason for hiding this comment

thockin commented Oct 24, 2014

derekwaynecarr commented Oct 24, 2014

derekwaynecarr commented Oct 24, 2014

bgrant0607 commented Oct 27, 2014

smarterclayton commented Oct 27, 2014

derekwaynecarr commented Oct 27, 2014

bgrant0607 commented Oct 28, 2014

bgrant0607 commented Oct 28, 2014

derekwaynecarr commented Oct 28, 2014

derekwaynecarr commented Oct 28, 2014

bgrant0607 commented Oct 29, 2014

derekwaynecarr commented Oct 29, 2014

bgrant0607 commented Oct 29, 2014

bgrant0607 commented Oct 29, 2014

derekwaynecarr commented Oct 30, 2014

bgrant0607 commented Jan 22, 2015

derekwaynecarr commented Jan 24, 2015