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
Version is critical because it defines schema.  Without schema you have very little guarantee your intent is applied.  Config and objects on disk should always have version - it should be extremely rare not to.  That vagueness results in unspecified behavior.


> On Oct 27, 2014, at 12:07 PM, 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)
> Imho, while doing the Config bulk operations, you need to get the "Kind" only. But yeah, you're right that the deserialization should be done just once. Ok.
> 
> —
> Reply to this email directly or view it on GitHub.