wsk namespace list lists all namespaces, which is good.
wsk namespace get <namespace> seems to list all entities in a given namespace. however, when trying this out i always get the entities in the current namespace. besides that wsk namespace get seems to deliver the same results as wsk list, with the difference that wsk namespace get accepts the namespace to list as a parameter.
as an alternative, i'd suggest to eliminate wsk namespace get, and instead introduce sth like wsk namespace switch-to <namespace>
I'll guess that when you specified the namespace on get you omitted the leading / as in wsk namespace get x vs wsk namespace get /x. The leading / on an namespace is required in all CLI commands that refer to a namespace (rationale being that this indicates a change of a top level "path").
wsk namespace list lists namespaces without the leading slash. so for consistency, i'd suggest we either list them with leading / or allow wsk namespace get to work with no leading /.
besides that -- i think think it's irritating to get the content of a different namespace listed when missing the / -- an error msg would be more appropriate.
tried in go-cli and doesn't matter what value I pass for NAMESPACE with / or without /
Also I think it should required user to specify leading /
$ wsk -v namespace get -h
get triggers, actions, and rules in the registry for a namespace
Usage:
wsk namespace get [NAMESPACE] [flags]
Global Flags:
--apihost HOST whisk API HOST
--apiversion VERSION whisk API VERSION
-u, --auth KEY authorization KEY
-d, --debug debug level output
-i, --insecure bypass certificate checking
-v, --verbose verbose output
Check current namespace
$ wsk property get --namespace
whisk namespace user@us.ibm.com_openwhisk
List namespaces
$ wsk namespace list
namespaces
user@us.ibm.com_dev
user@us.ibm.com_openwhisk
a key is now unique to a namespace - so list returns only a singleton.
there is no switch operation supported in wsk since identity management is considered a separate concern.
we could delete wsk namespace get since it's probably not used given that we have wsk list.
@mbehrendt commented on Fri Jun 24 2016
wsk namespace list
lists all namespaces, which is good.wsk namespace get <namespace>
seems to list all entities in a given namespace. however, when trying this out i always get the entities in the current namespace. besides thatwsk namespace get
seems to deliver the same results aswsk list
, with the difference thatwsk namespace get
accepts the namespace to list as a parameter.as an alternative, i'd suggest to eliminate
wsk namespace get
, and instead introduce sth likewsk namespace switch-to <namespace>
@rabbah commented on Mon Jun 27 2016
I'll guess that when you specified the
namespace
onget
you omitted the leading/
as inwsk namespace get x
vswsk namespace get /x
. The leading/
on an namespace is required in all CLI commands that refer to a namespace (rationale being that this indicates a change of a top level "path").@mbehrendt commented on Mon Jun 27 2016
wsk namespace list
lists namespaces without the leading slash. so for consistency, i'd suggest we either list them with leading/
or allowwsk namespace get
to work with no leading/
.besides that -- i think think it's irritating to get the content of a different namespace listed when missing the
/
-- an error msg would be more appropriate.@csantanapr commented on Wed Sep 07 2016
tried in go-cli and doesn't matter what value I pass for NAMESPACE with / or without / Also I think it should required user to specify leading
/
Check current namespace
List namespaces
Try to get content for a specific namespace
Try without leading
/
try invalid namespace /foobar
It always uses the same value, and the input is never validated.
@dubeejw commented on Wed Sep 07 2016
@csantanapr, your issue will be address in https://github.com/openwhisk/openwhisk/pull/1211.
@rabbah commented on Thu Nov 16 2017
a key is now unique to a namespace - so list returns only a singleton. there is no switch operation supported in
wsk
since identity management is considered a separate concern. we could deletewsk namespace get
since it's probably not used given that we havewsk list
.@dubeejw @mdeuser thoughts?