Label all poolmgr-created resources with an id that's unique to a
running poolmgr instance. On poolmgr start up, clean up resources
created by old instances. Resources that are idle are killed
immediately; resources that could be running a user function are
killed after the maximum function timeout.
Addresses issue #51. Makes versioning in poolmgr explicit, so its
cache needs no invalidation on version update. Functions in poolmgr
are always cached by name and UID.
Router now updates implictly versioned routes with the latest version
of a function.
This means that users will see requests to implicitly-versioned routes
go to the latest version of a function within 3 seconds. (Those 3 sec
will go away when we use a real watch instead of polling the
controller.)
There's no change in behaviour for routes that explictly specify a
function UID.
A defer statement contained an access to a pointer that was set to
nil before the deferred statement was run; remove it and just
explicity run the statement.
Idle pod reaper wakes up once a minute, looks in the functionServiceCache for pods that
haven't been accessed for more than idlePodReapTime, and deletes all such pods.
(This doesn't yet delete pods that may be leaked from previously terminated poolmgrs; it
only works with pods created by the current poolmgr instance.)
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.
Delete pods that are unused for more than a certain timeout. This
change isn't complete -- other funcSvc caches need to be invalidated
on delete. This needs a bit of refactoring.
Poolmgr needs to know usage statistics for a function's pod. This
change asynchronously taps poolmgr API when router uses a service.
Poolmgr can use this information to control pod expiry. It may also
be useful later as one of the metrics for autoscaling.
Even though the K8s api returns quickly after creating a service, that
service doesn't seem usage until about a second or two later. We need
to investigate this and see if there's something we can do to make it
faster. If there isn't we'll remove the svc code entirely; for now
it's behind a useSvc flag that's set to false.
If the pool is new or very busy, we may call the chosen container's
specialize endpoint before it's actually up -- handle the case by
retrying a few times.
Also namespace-qualify service hostname (since router and
functions run in different namespaces).
:= 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.
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)
