WIP - Allow kubectl to handle arbitrary objects

Kubectl will need to handle extension of object types for known (part of api.Scheme)
and unknown (defined via config or future ComponentPlugin extension mechanisms) from
the API server.  This pull request updates the create/update/delete flows for kubectl
to separate the versioning abstractions from the core code path via interfaces.

I will update the other code paths (get / describe) once we get through this review.
@ghodss @fabianofranz

The pull also contains unification of ResourceVersioner and SelfLinker and starts
using it within Kubectl. @lavalamp
I don't think we've ever come across enough places that use only one to split it.  Also, it does a fairly expensive operation (deserialize from JSON) which shouldn't be done twice.


> On Oct 27, 2014, at 10:57 AM, Vojtech Vitek <notifications@github.com> wrote:
> 
> In pkg/kubectl/interfaces.go:
> 
> > +	"github.com/GoogleCloudPlatform/kubernetes/pkg/runtime"
> > +)
> > +
> > +// RESTClient is a client helper for dealing with RESTful resources
> > +// in a generic way.
> > +type RESTClient interface {
> > +	Get() *client.Request
> > +	Post() *client.Request
> > +	Delete() *client.Request
> > +	Put() *client.Request
> > +}
> > +
> > +// ObjectTyper contains methods for extracting the APIVersion and Kind
> > +// of objects.
> > +type ObjectTyper interface {
> > +	DataVersionAndKind([]byte) (version, kind string, err error)
> Why do we couple Version and Kind? Would it make sense to split this to DataVersion() and DataKind()?
> 
> —
> Reply to this email directly or view it on GitHub.