Soam Vasani
Soam Vasani
We should expose gauges for how much memory and cpu is used by a function. That will give users a historical record of a functions resource usage (and its cost).
Today, functions can either choose poolmgr or newdeploy, and only the newdeploy backend supports the horizontal autoscaler. Therefore users have to choose between fast cold starts (i.e. low latencies) or...
The `kubewatcher` service is pretty much independent of Fission. Only the API is dependent on the fission.Watch type, which may as well be a K8s resource; then watchSync.go can be...
Kubewatcher today only has a webhook publisher; investigate adding a NATS-Streaming-based publisher for reliable message delivery.
kubewatcher can't currently watch Kubernetes ThirdPartyResources. We should add support for that. We will probably have to change the serialization stuff to be smarter, or maybe we can use lower...
For various reasons, a function execution can fail: node failure, network failure, failure of some of its dependencies, etc. If the trigger is a fault-tolerant message queue, or if the...
With the fission builder framework, each language environment can have a builder and a runtime. With Heroku (and Deis), users can specify a set of buildpacks and use heroku (or...
Today we have a `Literal []byte` in the Archive type, which allows us to serialize small packages into the Kubernetes TPR/CRD object itself. However this results in a base64-encoded blob...
We should systematically measure the cold-start performance of fission functions, and measure their variation along a few variables: * environments * invoke strategies (especially poolsize) * future features like deployment...