WIP: Add atomic resource reservation to nodes.

Add explicit resource reservation to nodes.  To be used to handle port allocation amongst other things. 

Only updated a single types.go, since I expect some iteration here.  Will update all types when we reach consensus.
I was going to have the resource key be: "port:<portNum>", then Service or
Scheduler can atomically reserve the port.  Obviously they need to roll
back, if the usage somehow fails, and we probably need a GC/Reaper to make
sure that we don't leak ports, but that would work correctly.

--brendan

On Mon, Nov 3, 2014 at 2:47 PM, Daniel Smith <notifications@github.com>
wrote:

> In pkg/api/types.go:
>
> > @@ -531,6 +531,8 @@ type EndpointsList struct {
> >  type NodeResources struct {
> >  	// Capacity represents the available resources.
> >  	Capacity ResourceList `json:"capacity,omitempty" yaml:"capacity,omitempty"`
> > +	// Usage represents the currently used resources.
> > +	Usage ResourceList `json:"usage,omitempty" yaml:"usage,omitempty"`
>
> How are you going to fit ports into the ResourceList, anyway?
>
> Ports-in-use is a derived property; the only reason to track it at the
> node is caching.
>
> We can't do atomicity properly because assigning a pod/service to a minion
> is a multi-object transformation.
>
> Perhaps an easy solution is to generate, for each service wanting external
> traffic, a pod constrained to minions with external IPs that can forward to
> the service. (Wrap our proxy up in a pod?) Then our existing port tracking
> would be sufficient.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/GoogleCloudPlatform/kubernetes/pull/2093/files#r19773197>
> .
>