Establish a proxy server from the controller to the log database.
Redirect query commands send from client to database then proxy back the db response.
Use parameter binding instead of fmt.Sprintf to prevent SQL injection.
Add function log aggregation and persistence using Fluentd and InfluxDB.
Fluentd and a helper sidecar run as a daemonset. The poolmgr sets up logging for each function pod, using the helper sidecar. Fluentd forwards logs to InfluxDB, which is run as a deployment and service. The client CLI directly queries InfluxDB for logs.
Fluentd supports many outputs besides InfluxDB, so we aren't very tied to InfluxDB.
The setup is somewhat manual, which we should be able to improve by integrating this into the helm chart.
Diagram of component interactions: https://cloud.githubusercontent.com/assets/202578/23100399/b0e3ea00-f6ba-11e6-8f2f-6588cfef2e84.png
Minimal golang runtime.
Functions are built as Go plugins, and the plugin is uploaded to fission.
See `environments/go/README.md` for instructions and `examples/go` for a usage example.
For now, we're re-using the 'code' field of the function to store the binary plugin. With v2 environments, this will be stored separately as a binary package.
This allows users to add --method and --url params to their "fission
fn create" command line. It sets up the route to call the latest
version of the function; user can edit the route with the "fission
route update" command, if they want to.
The new command invokes editor on a copy of the source code, and
uploads the new source code. It's an easy way to manually edit
functions from a terminal.
