`faas list` does not seem to work about func

[lance]

Update: it's listing only functions deployed to the faas namespace.

[lkingland]

Upon thinking about this a bit, I think the most broadly compatible option here might be to consider that the FaaS system, when using a Kubernetes cluster as the underlying Platform, always delegates to the K8S client for making requests. This client is already configured using ~/.kube/config, which includes the currently active namespace.
So how about, in all cases, we let the currently configured namespace be determined by that system (the docs currently recommend setting this during configuration):

kubectl config set-context --current --namespace=faas

Then we confirm that our code does not interfere with this setting.

By keeping the namespace configuration as a layer "below" the faas system (in the same way we expect the currently active cluster to be abstracted, credentials, connection address, etc) we are not only preventing a leak through the Platform abstraction, we're also allowing for support of different platforms which don't have the namespace concept.

Alternately, if we really do want to expose the concept of namespace through the abstraction, we would just need to agree to be on the hook to create a sensible default implementation in situations where namespace does not exist by default, such as localhost, other cluster types, etc. We would then just add this setting in the .faas.config such that the Faas Client can find the Function on subsequent invocations. Thoughts??

[lance]

So how about, in all cases, we let the currently configured namespace be determined by that system (the docs currently recommend setting this during configuration)

Agree. I don't think this eliminates the need for a --namespace flag though.

Alternately, if we really do want to expose the concept of namespace through the abstraction, we would just need to agree to be on the hook to create a sensible default implementation in situations where namespace does not exist by default, such as localhost, other cluster types, etc.

This should be taken under consideration, for sure. However, I think for an initial Dev Preview release, we can assume that localhost and Kube/OCP are the only two supported platforms. In this case, I'm not sure that there is much to really do other than be clear that delete, deploy update and list commands are only relevant in the context of remote Kube/OCP deployments.

[lkingland]

OK, so we'll default to using the kubectl-defined namespace (not override), but if supplied, use it. Additionally, in platforms that do not utilize the setting, for now it is ignored.

It seems to me upon reflection that, regardless of underlying platform (be that Kubernetes, localhost, or some future platform made deployable via Grid), that the concept of a namespace will be useful if not necessary for anything beyond toy deployments. Woe be unto those who add complexity at such an early stage, but this may be part of the Irreducible Complexity of function-as-a-service offering.

[lance]

Fixed in #78