[WIP] Idling Proposal

There will be a local Kube proxy on hosts running the router, and the router has all of info the Kube proxy needs.  The router could start and stop a proxy when running off a node, or connect through to the local Kube proxy.  If in the future we need a specific unidler, we can adapt the existing mechanism.


> On Dec 17, 2014, at 2:57 PM, Andy Goldstein <notifications@github.com> wrote:
> 
> In docs/idling.md:
> 
> > +We also know that the edge routing layer must:
> > +
> > +1.  Track idleness of services
> > +1.  Initiate an unidle in response to a request to an idled service
> > +1.  Allow buffering of requests to idled services.
> > +
> > +#### Should the edge router buffer requests or always delegate?
> > +
> > +There are many possible scenarios for how unidling functionality should be implemented across the
> > +edge routing and kube-proxy layers.  Fundamentally they decompose into two cases: the edge
> > +routing layer handles buffering of requests in addition to the kube-proxy layer or delegates to the
> > +kube-proxy layer to buffer connections.  The problem with having both layers independently buffer
> > +requests when the other has initiated the unidle is that it introduces shared state.  If the edge
> > +routing layer delegates to the kube-proxy layer for idled services, requests to unidling services
> > +will be buffered by the kube-proxy layer.  For this reason, we recommend that the edge routing
> > +layer not buffer requests itself.
> @pmorie but what if you're unlucky and pick the wrong node (which is offline)?
> 
> —
> Reply to this email directly or view it on GitHub.
>