Quick Highlight

OpenAPI 2.0 (Swagger) API doc

As a long asking feature, now you can access OpenAPI 2.0 doc, which is also known as Swagger API doc, through the controller endpoint.

$ kubectl -n fission proxy
Starting to serve on

The API document will be available at the following URL.


# Example
$ wget http://localhost:8001/api/v1/namespaces/fission/services/controller:80/proxy/v2/apidocs.json

Go to https://editor.swagger.io/.

File > Import File

NOTE: You may encounter the CORS issue when using Import URL, please download the API document instead.

You shall see the beautiful api doc.

OpenAPI 2.0 doc

For details, see here and PR#85.

Configurable spec deployment UID

Previously, fission spec init generated a random deployment UID every time to ensure that each deployment is unique. And Fission uses the UID to find out and upgrades all resources related to the deployment.

In the original idea, developers create a GIT repository to store the spec files and update some of them when necessary. This workflow works well for normal use cases. But in some cases this becomes a problem. Imagine a company with fully automated CI pipelines that generates the spec files dynamically, the UID will be different every time and make it difficult for users to upgrade the previous deployment.

But now you can assign UID when doing fission spec init to prevent such problem.

$ fission spec init --deployid test-foo-bar

For details, see here and PR#1249.

Configurable specialization timeout for function with newdeploy executor

Different functions may require different lengths of time for executor to specialize function pods. Now, you can specify the timeout setting through --specializationtimeout while creating the function. If the flag is not provided, a default timeout 120s will be used.

$ fission fn create --name h1 --env nodejs --code hello.js --specializationtimeout 100 --executor newdeploy

Note: In 1.5.0, the specialization timeout setting is only available for newdeploy executor.

For details, see here and PR#1260.

Access full request URL in functions

Before, if a user creates an endpoint with path parameter(s) in URL, once the router receives requests the endpoint it will parse the target URL and attach parameter(s) to requests headers.

For example, a user creates a http trigger with URL /foo/py1/{test} points to a function, the request header is like

$ curl http://<router>/foo/py1/bar

# header

Due to this, the function is not able to distinguish and have different actions based on the full URL path. But now, you can access the full URL value through header X-Fission-Full-Url.


For details, see here and PR#1266.

Access multiple configmaps & secrets in functions

Now, you can create a function that references multiple configmaps and secrets via CLI.

# Provide multiple Configmaps
$ fission fn create --name <fn-name> --env <env-name> --code <your-source> --configmap <configmap-one> --configmap <configmap-two>

# Provide multiple Secrets
$ fission fn create --name <fn-name> --env <env-name> --code <your-source> --secret <secret-one> --secret <secret-two>

For details, see here and PR#1282.