1.7.0
Critical Fix
Request gets closed before receiving full response body
A critical issue that caused router closes requests before fully sending response body back to client has been fixed.
For details, see issue and PR.
Quick Highlight
Migrate from urfave/cli to spf13/cobra
As the Fission has evolved, more and more commands and flags are added to CLI. To keep CLI as simple as possible, we also need to deprecate some of the flags to prevent confusion.
Consider the CLI package (urfave/cli) has not been shipped out any official release for a long time and missing features that are important for code repair. We decided to seek another CLI package to replace it.
The new package must fulfill following requirements:
- Popularity: the package must be widely adopted by communities
- Comprehensive docs and tutorials
- Allow marking a flag as required/deprecated/hidden
- Easy to add sub-commands
After evaluation and some experiments, we decided to use spf13/cobra, which fulfills all requirements above. Also, it’s adopted by big projects like Kubernetes and Moby.
Since all CLI commands have been rewritten, if you see any inconsistent behavior for CLI command in 1.7.0, please file an issue.
For details, see PR.
Orphaned resource adoption for executor
The executor used to be a stateful application that stores all kubernetes resources information it created in memory. Store in memory means we are not able to retrieve information back if executor pod gets deleted/restarted. So when a new executor starts, it detects and removes the kubernetes objects created by the deleted executors in order to rebuild the resources map. However, this approach may affect alive requests to function pods and terminates/deletes all existing pods when executor starts.
In 1.7.0, we use annotations to store all necessary information for resource adoption. Also, an experiment feature allows the executor to adopt existing orphaned kubernetes objects has been added to the codebase. Once the adoption feature enabled, whenever a new executor starts it will first try to adopt all resources created by the old executor instead of removing them like before.
There are no silver bullets, this adoption feature increases the overall startup time of executor if there are huge amounts of resources exist in the cluster. Also, requests to function that have no function pods exists yet will fail due to the executor is still in boot up process. The executor will wait at most 30 seconds for resources adoption, after that executor will start API service.
You can enable this feature by specify executor.adoptExistingResources to true when installing/upgrading Fission 1.7.0 with helm.
--set executor.adoptExistingResources=true
Or, you can enable it by modifying environment variable of deployment of executor.
- name: ADOPT_EXISTING_RESOURCES
value: "true"
The executor will still delete resources when you upgrade from a version prior 1.7.0 even the feature is enabled.
For details, see PR.
OpenShift support
For how to install Fission on OpenShift, please visit here
If you have any issues when installing Fission on OpenShift, feel free to open an issue.
For details, see PR.
URL as archive source when creating functions/packages
Previously, the CLI tends to download the file and upload it to internal storagsvc to persist when a user provides URL as archive source while creating the package. This approach increases the total package creation time if the file size is large.
As of 1.7.0, the CLI embeds the given URL in package archive directly. This approach brings couple benefits:
- Shorten package creation time.
- Increase the portability of fission spec file.
$ fission pkg create --spec --name dummy-package2 --env nodejs \
--code https://raw.githubusercontent.com/fission/examples/main/nodejs/hello.js
which results in
apiVersion: fission.io/v1
kind: Package
metadata:
creationTimestamp: null
name: dummy-package2
namespace: default
spec:
deployment:
checksum: {}
type: url
url: https://raw.githubusercontent.com/fission/examples/main/nodejs/hello.js
....
And you will notice the CLI still tends to download the file in order to generate the SHA256 checksum to prevent the file changed.
Downloading file to generate SHA256 checksum. To skip this step, please use --srcchecksum / --deploychecksum / --insecure
You can either use --srcchecksum or --deploychecksum or --insecure to bypass the download steps.
For details, see PR1360 and PR1430
Display HTTP trigger access log
To show HTTP trigger access log, you have to set
router.displayAccessLog=true
when using helm to deploy 1.7.0. Or, you can change the environment variable DISPLAY_ACCESS_LOG of router deployment to "true".
Once enabling endpoint access log, the router resource utilization increases when under heavy workloads.
For details, see PR.
Update Prometheus chart version from 7.1.0 to 9.3.1
Starting in Kubernetes 1.16, Deployment resources that specify extensions/v1beta1 as the API group will be rejected.
The deprecation of old API group fails the deployment of Prometheus chart prior version 9.3.0.
To avoid deployment failure, we’ve upgraded the Prometheus chart version to 9.3.1.
For details, see PR.
Specialization timeout for pool manager
Start from 1.5.0, newdeploy allows setting --specializationtimeout for function.
And now you can specify the timeout setting for functions that use poolmanager as executor type.
$ fission fn create --name h1 --env nodejs --code hello.js --specializationtimeout 120 --executor poolmanager
For details, see PR.
ProbabilitySampler in router
ProbabilitySampler returns True or False for whether a span should be sampled depending on the results of a coin flip [1].
To change probability of sampler, you can set
router.traceSamplingRate=0.01
when using helm to deploy 1.7.0.
Or, you can change the environment variable TRACING_SAMPLING_RATE of router deployment to any value you want.
If the value of router.traceSamplingRate is 1 means to sample all incoming requests and 0 means to disable it.
For details, see PR.
[1] https://opencensus.io/tracing/sampling/probabilistic/
Set API type for Tensorflow Serving function
Tensorflow Serving supports three kinds of API: predict, classify, regress.
You can specify the API kind in entry point in the format <model-name>:<API kind>.
$ fission fn create --name t1 --pkg <pkg name> \
--env tensorflow --entrypoint "half_plus_two:regress"
The server inside function pod splits entry point to get model name and API kind. When requests go to the pod, the server will then appends API type to proxy URL in order to hit the correct Tensorflow Serving API.
For details, see PR.
PodSpec support in environment builder
PodSpec was introduced in Environment runtime for a period, people can add volumes or nodeSelector to function pod if needed.
Now, the environment builder also supports PodSpec. Please check the merge rules before using this feature.
For details, see PR.