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.
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)
Fetcher is a tool to download functions from the controller. It is
meant to be run in a container in the same pod as the function run
container, with a shared volume.
Environments for functions. For now this is just the image URL for the
function run container. In the future, Environments will also have
build container image URLs, and perhaps parameters to those
containers.
Create/read/update/delete/list. Versioning will be added later. For
now, only the latest update is stored.
This implemenents create/read/update/delete/list for http triggers.
This isn't quite the final implementation: you can't look up old
versions by UUID since it only stores the latest update. I'll get to
that later.
FunctionStore uses fileStore for function code and resourceStore for
the Function's metadata. Environment- and HTTPTrigger- Store are just
thin wrappers on resourceStore.
There is probably a better way to organize this code, maybe with
reflection.
- A generic Resource interface, which is serializable and has
a key() method to get an identifying key.
- A resourceStore, which has create, read, update, delete and list.
This wraps etcd key operations and serialization/deserialization in
a convenient service. Serialization is provided to the
resourceStore as a 'serialization' interface. This can be JSON or
anything else.
- The resourceStore also has file operations -- this has read, write
and delete operations. The general idea is to store metadata in
etcd and data on the fileStore (which could also be an object store,
we don't really use any file-specific properties). Files are also
versioned -- each writeFile writes to a new UUID and that UUID is
stored in an etcd in-order list. readFile can retrieve an arbitrary
version by UUID, or just get the latest contents.
Soam Vasani