Commit Graph
5 Commits
Author SHA1 Message Date
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