Yet more non-controversial fixes from #2277

Fixing namespace handling + kubectl describe refactor
Describe shouldn't know about clients, because as soon as we have component plugins there will just be generic describe and specific describe, but different objects will have different RESTClients (i.e. kubectl looking at OpenShift as a component plugin wouldn't have binary code for describe in process but would need to build urls against server X).  I'm kind of hedging a lot of client code until we can come to a componentplugin story that solves all the problems.  Proxying for auth or not is the hardest decision.  I think proxying has a scale problem in a very large cluster (you wouldn't want all API traffic of all component plugins going through a master), so I would lean towards each client has their own endpoints and there is no homogenous resource path.  So then you'd fetch component plugins from a client, get the redirect URI for their base and build a rest client pointing to that (component either is one per resource or gives you the URL that lists resources).  You'd pass the appropriate rest client into the describer, but it wouldn't be a straight *client.Client.

----- Original Message -----
> > @@ -38,29 +38,13 @@ type Describer interface {
> >  func DescriberFor(kind string, c *client.Client) (Describer, bool) {
> >  	switch kind {
> >  	case "Pod":
> > -		return &PodDescriber{
> 
> Ah, thanks for explanation, I couldn't understand why this code was the way
> it was: it looked like a lot of unnecessary boilerplate.
> 
> If that was the goal, why not make the Describe function take a client as a
> parameter? No need to bake the client into the object at all.
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/GoogleCloudPlatform/kubernetes/pull/2367/files#r20390829