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/master/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/master/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.

Last modified September 28, 2021: Fission docsy newsite with blog and docs merged (#39) (4320c0b)