Commit Graph
8 Commits
Author SHA1 Message Date
Soam Vasani 9aab4f0795 Move client-go dependency to 1.5
Client 1.5 is compatible with Kubernetes version 1.3 through 1.5.
2016-11-14 16:25:23 -08:00
Soam Vasani 5650fca3fd Refactor caching in poolmgr
Move separate caches to one cache -- functionServiceCache.  It can be
looked up by function, can update atime by address, and can be deleted
by podname.  This removes the other caches.  Some of the concurrency
logic is still a bit hairy; it might be better not to use fission.Cache.
2016-11-05 22:03:48 -07:00
Soam Vasani 5cfe4b7c1d Log and ignore errors on eager pool creation 2016-11-04 23:05:29 -07:00
Soam Vasani a6cd6e99fe Eagerly create generic pools
Poolmgr now watches the controller's list of environments and eagerly
creates a generic pool for each environment, if one doesn't already exist.
2016-11-03 15:08:06 -07:00
Soam Vasani bb687d3e98 Don't use := when some vars are defined
:= attempts to declare as many of the variables on its left side as it
can, instead of re-using as many as it can.  Consider this code:

   a, ok := foo()
   if !ok {
      a, err := bar()
      ...
   }

The inner 'a' is a different var from the outer one, and goes out of
scope at the }.  The outer 'a' is left with whatever value foo()
returned.
2016-11-02 20:29:21 -07:00
Soam Vasani 91eb0ca3cd Poolmgr bugfix -- remove double response on the same channel 2016-11-02 15:47:32 -07:00
Soam Vasani 40dfba1a41 Switch to official Kubernetes Go client -- client-go/1.4
Switch to client-go package instead of pulling the from kubernetes.
Use a versioned client with sensible compatiblity.

This change breaks 'go get'.  For now you have to manually checkout
the 'release-1.4' branch of the client-go package after 'go get'
fetches it.  TODO: use one of the build tools to fix this.
2016-11-01 01:32:02 -07:00
Soam Vasani 7d1058d7be Pool Manager -- manage generic containers and their specialization
GenericPool is a pool of generic containers for an environment.
GenericPoolManager keeps track of all GenericPools, creating them
on-demand.

The pool manager API is simply a "lookup" for the service URL of a
function.  If one exists it is returned immediately; otherwise, a
generic pool is created, and then a pod is specialized from that pool.

poolmgr is designed to run from within the cluster, since it connects
to pod IP addresses directly.

This is a first cut with many pieces missing.

TODO:
* Use versioned kubernetes clients instead of the unversioned one
* Unit tests for GenericPoolMgr; improve unit test for GenericPool;
  test for API.
* Handle cases where a service exists but pod backing it has failed.
* On start up, use existing deployments/pods/services if they exist;
  in other words don't orphan resources on restart.
* Kill idle resources (services, pods, even generic pools)
* Autoscale generic pool (for example, by watching num ready pods)
2016-11-01 01:32:02 -07:00