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



> On Sep 29, 2014, at 11:47 PM, Tim Hockin <notifications@github.com> wrote:
> 
> In pkg/api/v1beta3/types.go:
> 
> >  
> >  	// ContainerPort is the name of the port on the container to direct traffic to.
> >  	// Optional, if unspecified use the first port on the container.
> >  	ContainerPort util.IntOrString `json:"containerPort,omitempty" yaml:"containerPort,omitempty"`
> >  }
> >  
> > -func (*Service) IsAnAPIObject() {}
> > +// Service is a named abstraction of software service (for example, mysql) consisting of local port
> > +// (for example 3306) that the proxy listens on, and the selector that determines which pods
> > +// will answer requests sent through the proxy.
> > +type Service struct {
> Cross-referencing this with the ip-per-service PR, I have a question. In ip-per-service, the master has to assign a few fields (the IP in particular) to a service upon creation. They must be ignored on input.
> 
> Do you see those fields a) in ServiceSpec, b) in Service, c) in ServiceData, d) in BoundService ?
> 
Seems like ServiceStatus if users can never choose them.  If the users can set them or leave it to the server to set a default, maybe we use Spec for user intent and Status for effective state?  I feel like the Bound* are more special cases where things are transformed into other atomic units but that's more based on our current pattern.
> —
> Reply to this email directly or view it on GitHub.