openshift-docs/modules/serverless-functions-func-yaml-fields.adoc

// Module included in the following assemblies:
//
// * serverless/functions/serverless-functions-yaml.adoc

:_mod-docs-content-type: REFERENCE
[id="serverless-functions-func-yaml_{context}"]
= Configurable fields in func.yaml

Many of the fields in `func.yaml` are generated automatically when you create, build, and deploy your function. However, there are also fields that you modify manually to change things, such as the function name or the image name.

[id="serverless-functions-func-yaml-buildenvs_{context}"]
== buildEnvs

The `buildEnvs` field enables you to set environment variables to be available to the environment that builds your function. Unlike variables set using `envs`, a variable set using `buildEnv` is not available during function runtime.

You can set a `buildEnv` variable directly from a value. In the following example, the `buildEnv` variable named `EXAMPLE1` is directly assigned the `one` value:

[source,yaml]
----
buildEnvs:
- name: EXAMPLE1
  value: one
----

You can also set a `buildEnv` variable from a local environment variable. In the following example, the `buildEnv` variable named `EXAMPLE2` is assigned the value of the `LOCAL_ENV_VAR` local environment variable:

[source,yaml]
----
buildEnvs:
- name: EXAMPLE1
  value: '{{ env:LOCAL_ENV_VAR }}'
----

[id="serverless-functions-func-yaml-envs_{context}"]
== envs

The `envs` field enables you to set environment variables to be available to your function at runtime. You can set an environment variable in several different ways:

. Directly from a value.
. From a value assigned to a local environment variable. See the section "Referencing local environment variables from func.yaml fields" for more information.
. From a key-value pair stored in a secret or config map.
. You can also import all key-value pairs stored in a secret or config map, with keys used as names of the created environment variables.

This examples demonstrates the different ways to set an environment variable:

[source,yaml]
----
name: test
namespace: ""
runtime: go
...
envs:
- name: EXAMPLE1 <1>
  value: value
- name: EXAMPLE2 <2>
  value: '{{ env:LOCAL_ENV_VALUE }}'
- name: EXAMPLE3 <3>
  value: '{{ secret:mysecret:key }}'
- name: EXAMPLE4 <4>
  value: '{{ configMap:myconfigmap:key }}'
- value: '{{ secret:mysecret2 }}' <5>
- value: '{{ configMap:myconfigmap2 }}' <6>
----
<1> An environment variable set directly from a value.
<2> An environment variable set from a value assigned to a local environment variable.
<3> An environment variable assigned from a key-value pair stored in a secret.
<4> An environment variable assigned from a key-value pair stored in a config map.
<5> A set of environment variables imported from key-value pairs of a secret.
<6> A set of environment variables imported from key-value pairs of a config map.

[id="serverless-functions-func-yaml-builder_{context}"]
== builder

The `builder` field specifies the strategy used by the function to build the image. It accepts values of `pack` or `s2i`.

[id="serverless-functions-func-yaml-build_{context}"]
== build

The `build` field indicates how the function should be built. The value `local` indicates that the function is built locally on your machine. The value `git` indicates that the function is built on a cluster by using the values specified in the `git` field.

[id="serverless-functions-func-yaml-volumes_{context}"]
== volumes

The `volumes` field enables you to mount secrets and config maps as a volume accessible to the function at the specified path, as shown in the following example:

[source,yaml]
----
name: test
namespace: ""
runtime: go
...
volumes:
- secret: mysecret <1>
  path: /workspace/secret
- configMap: myconfigmap <2>
  path: /workspace/configmap
----
<1> The `mysecret` secret is mounted as a volume residing at `/workspace/secret`.
<2> The `myconfigmap` config map is mounted as a volume residing at `/workspace/configmap`.

[id="serverless-functions-func-yaml-options_{context}"]
== options

The `options` field enables you to modify Knative Service properties for the deployed function, such as autoscaling. If these options are not set, the default ones are used.

These options are available:

* `scale`
** `min`: The minimum number of replicas. Must be a non-negative integer. The default is 0.
** `max`: The maximum number of replicas. Must be a non-negative integer. The default is 0, which means no limit.
** `metric`: Defines which metric type is watched by the Autoscaler. It can be set to `concurrency`, which is the default, or `rps`.
** `target`: Recommendation for when to scale up based on the number of concurrently incoming requests. The `target` option can be a float value greater than 0.01. The default is 100, unless the `options.resources.limits.concurrency` is set, in which case `target` defaults to its value.
** `utilization`: Percentage of concurrent requests utilization allowed before scaling up. It can be a float value between 1 and 100. The default is 70.
* `resources`
** `requests`
*** `cpu`: A CPU resource request for the container with deployed function.
*** `memory`: A memory resource request for the container with deployed function.
** `limits`
*** `cpu`: A CPU resource limit for the container with deployed function.
*** `memory`: A memory resource limit for the container with deployed function.
*** `concurrency`: Hard Limit of concurrent requests to be processed by a single replica. It can be integer value greater than or equal to 0, default is 0 - meaning no limit.

This is an example configuration of the `scale` options:

[source,yaml]
----
name: test
namespace: ""
runtime: go
...
options:
  scale:
    min: 0
    max: 10
    metric: concurrency
    target: 75
    utilization: 75
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 1000m
      memory: 256Mi
      concurrency: 100
----

[id="serverless-functions-func-yaml-image_{context}"]
== image

The `image` field sets the image name for your function after it has been built. You can modify this field. If you do, the next time you run `kn func build` or `kn func deploy`, the function image will be created with the new name.

[id="serverless-functions-func-yaml-imagedigest_{context}"]
== imageDigest

The `imageDigest` field contains the SHA256 hash of the image manifest when the function is deployed. Do not modify this value.

[id="serverless-functions-func-yaml-labels_{context}"]
== labels

The `labels` field enables you to set labels on a deployed function.

You can set a label directly from a value. In the following example, the label with the `role` key is directly assigned the value of `backend`:

[source,yaml]
----
labels:
- key: role
  value: backend
----

You can also set a label from a local environment variable. In the following example, the label with the `author` key is assigned the value of the `USER` local environment variable:

[source,yaml]
----
labels:
- key: author
  value: '{{ env:USER }}'
----

[id="serverless-functions-func-yaml-name_{context}"]
== name

The `name` field defines the name of your function. This value is used as the name of your Knative service when it is deployed. You can change this field to rename the function on subsequent deployments.

[id="serverless-functions-func-yaml-namespace_{context}"]
== namespace

The `namespace` field specifies the namespace in which your function is deployed.

[id="serverless-functions-func-yaml-runtime_{context}"]
== runtime

The `runtime` field specifies the language runtime for your function, for example, `python`.