Proposal: v1beta3 API overhaul

Speculative change for some items from #1200:

* Metadata that applies to resources is split from APIMetadata on non-resource API objects
* Metadata is a sub field of objects
* Labels are on Metadata
* Pod current and desired state is split
* Name is used for pods instead of ID (UID is part of metadata, Name is part of resource) for idempotent creation #148 and #1216 
* PodTemplate is a Metadata carrying object as per #170
 * If replicationController gave way to a generic "replicator", then pod template could be both a nested struct and a real resource.
* A ScheduledPod and ScheduledPodList is what the kubelet sees as per #860
* Non-schema'd k/v values on Metadata as `Config` (better names welcome) as per #1201

Not changed yet:

* ReplicationControllers
* Services

EDIT: Moving to higher bandwidth document here: https://docs.google.com/document/d/1E_HNsbyocweD9zJHXbz5Xb9XPwBqvDnLHhGeBq15FlI/edit?usp=sharing
I think the argument about being able to easily (from a client) map the "metadata" field to a specific object type won the argument for me at least.  If someone can articulate a new counter argument to "metadata" as a sub object (will regard it as the current argument) please do so in the next few days.

----- Original Message -----
> > +   Lists have a limited set of common metadata. All lists use the "items"
> > field to contain the array of objects they return. Each resource kind
> > should have an endpoint that returns the full set of resources, as well as
> > zero or more endpoints that return subsets of the full list.
> > +
> > +The standard REST verbs (defined below) MUST return singular JSON objects.
> > Some API endpoints may deviate from the strict REST pattern and return
> > resources that are not singular JSON objects, such as streams of JSON
> > objects or unstructured text log data.
> > +
> > +
> > +### Resources
> > +
> > +All singular JSON resources returned by an API MUST have the following
> > fields:
> > +
> > +* kind: a string that identifies the schema this object should have
> > +* apiVersion: a string that identifiers the version of the schema the
> > object should have
> > +
> > +
> > +### Objects
> > +
> > +Every object MUST have the following metadata in a nested object field
> > called "metadata":
> 
> Somewhere I thought I replied about making it easier to select out this group
> of fields in queries (GET ...?field=metadata), but I can't find that comment
> now.
> 
> Also, while Go appears to support inlining reasonably well even without
> Generics, I imagine that dealing with the metadata fields generically across
> object types without a common subobject may be challenging in some client
> languages.
> 
> However, it's probably not super-critical either way, and I don't want to
> bikeshed about this forever. If we do inline these fields, then I'm going to
> insist that we inline nothing else -- all other fields must be in
> subobjects.
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/GoogleCloudPlatform/kubernetes/pull/1225/files#r18062382