Rocky Series Release Notes

1.0.0

Prelude

Support versioning for functions. The function developer can work with different variations of a single function in the development workflow, such as development, beta, and production.

Qinling now can and by default connect to Kubernetes API server with TLS certificates.

Support customizing resource limitation for functions, both cpu and memory are supported.

New Features

  • Operators can now update the running configuration of the Qinling control plane processes by sending the parent process a “HUP” signal. Note: The configuration option must support mutation.

  • Support alias for functions. Users can create function alias pointing to the specific function version. Function alias can be used for creating execution, job and webhook.

  • Support versioning for functions. End users can create one or more versions for a single function, the code package of a function version is immutable. Each function version has a version number that can be used for creating execution, job and webhook.

  • Add an administrative operation for getting the pool information for the runtime, so that the admin user can check the capacity of the runtime and scale up or scale down the pool accordingly.

  • Support customizing memory and cpu resource limitation for functions. The user can specify memory_size and cpu when creating functions, otherwise the default values are used. Refer to Qinling documentation for more details.

  • Support to specify trusted for runtime creation. In Kubernetes orchestrator implementation, it’s using io.kubernetes.cri-o.TrustedSandbox annotation in the pod specification to choose the underlying container runtime. This feature is useful to leverage the security container technology such as Kata containers or gVisor. It also gets rid of the security concerns for running image type function.

Upgrade Notes

  • Re-apply the Kubernetes manifest file to grant NetworkPolicy resource operation permission to qinling user in Kubernetes, curl -sSL https://raw.githubusercontent.com/openstack/qinling/master/example/kubernetes/k8s_qinling_role.yaml | kubectl apply -f -

  • Qinling now by default will connect to Kubernetes API server using TLS certificates. For testing environments, users can set the use_api_certificate option to False under the kubernetes section in the Qinling configuration file to continue using insecure connection between Qinling and Kubernetes API server. For production environments, it is recommended to generate client certs for Qinling to access the Kubernetes API.

Security Issues

  • When using Kubernetes as the orchestrator, Qinling will create Kubernetes pods to run executions of functions. In Kubernetes, pods are non-isolated unless the NetworkPolicy is configured and enforced. In Qinling, we create NetworkPolicy to disable the communication between pods and the traffic from outside the cluster.