diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml index bcc806485d..62e6dc892a 100644 --- a/_topic_maps/_topic_map.yml +++ b/_topic_maps/_topic_map.yml @@ -3591,7 +3591,7 @@ Topics: File: serverless-developing-nodejs-functions - Name: Developing TypeScript functions File: serverless-developing-typescript-functions - - Name: Developing Golang functions + - Name: Developing Go functions File: serverless-developing-go-functions - Name: Developing Python functions File: serverless-developing-python-functions diff --git a/_topic_maps/_topic_map_osd.yml b/_topic_maps/_topic_map_osd.yml index 3f166a6d1a..94fc9ea718 100644 --- a/_topic_maps/_topic_map_osd.yml +++ b/_topic_maps/_topic_map_osd.yml @@ -326,7 +326,7 @@ Topics: File: serverless-developing-nodejs-functions - Name: Developing TypeScript functions File: serverless-developing-typescript-functions - - Name: Developing Golang functions + - Name: Developing Go functions File: serverless-developing-go-functions - Name: Developing Python functions File: serverless-developing-python-functions diff --git a/_topic_maps/_topic_map_rosa.yml b/_topic_maps/_topic_map_rosa.yml index 19db5e93dd..db1272a8c6 100644 --- a/_topic_maps/_topic_map_rosa.yml +++ b/_topic_maps/_topic_map_rosa.yml @@ -435,7 +435,7 @@ Topics: File: serverless-developing-nodejs-functions - Name: Developing TypeScript functions File: serverless-developing-typescript-functions - - Name: Developing Golang functions + - Name: Developing Go functions File: serverless-developing-go-functions - Name: Developing Python functions File: serverless-developing-python-functions diff --git a/cli_reference/index.adoc b/cli_reference/index.adoc index 6f9a89b1cd..6b4bbc18d6 100644 --- a/cli_reference/index.adoc +++ b/cli_reference/index.adoc @@ -24,7 +24,7 @@ The following set of CLI tools are available in {product-title}: * xref:../cli_reference/openshift_cli/getting-started-cli.adoc#cli-getting-started[OpenShift CLI (oc)]: This is the most commonly used CLI tool by {product-title} users. It helps both cluster administrators and developers to perform end-to-end operations across {product-title} using the terminal. Unlike the web console, it allows the user to work directly with the project source code using command scripts. -* xref:../cli_reference/kn-cli-tools.adoc#kn-cli-tools[Knative CLI (kn)]: The `kn` CLI tool provides simple and intuitive terminal commands that can be used to interact with OpenShift Serverless components, such as Knative Serving and Eventing. +* xref:../cli_reference/kn-cli-tools.adoc#kn-cli-tools[Knative CLI (kn)]: The Knative (`kn`) CLI tool provides simple and intuitive terminal commands that can be used to interact with OpenShift Serverless components, such as Knative Serving and Eventing. * xref:../cli_reference/tkn_cli/installing-tkn.adoc#installing-tkn[Pipelines CLI (tkn)]: OpenShift Pipelines is a continuous integration and continuous delivery (CI/CD) solution in {product-title}, which internally uses Tekton. The `tkn` CLI tool provides simple and intuitive commands to interact with OpenShift Pipelines using the terminal. diff --git a/cli_reference/kn-cli-tools.adoc b/cli_reference/kn-cli-tools.adoc index e090c293ce..e778f8128d 100644 --- a/cli_reference/kn-cli-tools.adoc +++ b/cli_reference/kn-cli-tools.adoc @@ -1,24 +1,24 @@ :_content-type: ASSEMBLY include::_attributes/common-attributes.adoc[] [id="kn-cli-tools"] -= Knative CLI (kn) for use with {ServerlessProductName} += Knative CLI for use with {ServerlessProductName} :context: kn-cli-tools toc::[] -The Knative `kn` CLI enables simple interaction with Knative components on {product-title}. +The Knative (`kn`) CLI enables simple interaction with Knative components on {product-title}. [id="kn-cli-tools-key-features"] == Key features -The `kn` CLI is designed to make serverless computing tasks simple and concise. -Key features of the `kn` CLI include: +The Knative (`kn`) CLI is designed to make serverless computing tasks simple and concise. +Key features of the Knative CLI include: * Deploy serverless applications from the command line. * Manage features of Knative Serving, such as services, revisions, and traffic-splitting. * Create and manage Knative Eventing components, such as event sources and triggers. * Create sink bindings to connect existing Kubernetes applications and Knative services. -* Extend the `kn` CLI with flexible plug-in architecture, similar to the `kubectl` CLI. +* Extend the Knative CLI with flexible plug-in architecture, similar to the `kubectl` CLI. * Configure autoscaling parameters for Knative services. * Scripted usage, such as waiting for the results of an operation, or deploying custom rollout and rollback strategies. diff --git a/modules/creating-serverless-apps-kn.adoc b/modules/creating-serverless-apps-kn.adoc index 11703e64fa..d43d64d872 100644 --- a/modules/creating-serverless-apps-kn.adoc +++ b/modules/creating-serverless-apps-kn.adoc @@ -7,12 +7,12 @@ [id="creating-serverless-apps-kn_{context}"] = Creating serverless applications by using the Knative CLI -Using the `kn` CLI to create serverless applications provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the `kn service create` command to create a basic serverless application using the `kn` CLI. +Using the Knative (`kn`) CLI to create serverless applications provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the `kn service create` command to create a basic serverless application. .Prerequisites * {ServerlessOperatorName} and Knative Serving are installed on your cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in {product-title}. .Procedure diff --git a/modules/delete-kn-trigger.adoc b/modules/delete-kn-trigger.adoc index d9556128f4..517bfc2b9a 100644 --- a/modules/delete-kn-trigger.adoc +++ b/modules/delete-kn-trigger.adoc @@ -6,7 +6,7 @@ [id="delete-kn-trigger_{context}"] = Deleting a trigger by using the Knative CLI -Using the `kn` CLI to delete a trigger provides a streamlined and intuitive user interface. You can use the `kn trigger delete` command to delete a trigger. +Using the Knative (`kn`) CLI to delete a trigger provides a streamlined and intuitive user interface. You can use the `kn trigger delete` command to delete a trigger. .Prerequisites diff --git a/modules/kn-trigger-describe.adoc b/modules/kn-trigger-describe.adoc index 6bcafe02f9..75494b664b 100644 --- a/modules/kn-trigger-describe.adoc +++ b/modules/kn-trigger-describe.adoc @@ -6,7 +6,7 @@ [id="kn-trigger-describe_{context}"] = Describing a trigger by using the Knative CLI -Using the `kn` CLI to describe triggers provides a streamlined and intuitive user interface. You can use the `kn trigger describe` command to print information about existing triggers in your cluster by using the `kn` CLI. +Using the Knative (`kn`) CLI to describe triggers provides a streamlined and intuitive user interface. You can use the `kn trigger describe` command to print information about existing triggers in your cluster by using the Knative CLI. .Prerequisites diff --git a/modules/kn-trigger-filtering.adoc b/modules/kn-trigger-filtering.adoc index cb3f5d5392..38d827e3bc 100644 --- a/modules/kn-trigger-filtering.adoc +++ b/modules/kn-trigger-filtering.adoc @@ -7,7 +7,7 @@ = Filtering events with triggers by using the Knative CLI // should be a procedure module but out of scope for this PR -Using the `kn` CLI to filter events by using triggers provides a streamlined and intuitive user interface. You can use the `kn trigger create` command, along with the appropriate flags, to filter events by using triggers. +Using the Knative (`kn`) CLI to filter events by using triggers provides a streamlined and intuitive user interface. You can use the `kn trigger create` command, along with the appropriate flags, to filter events by using triggers. In the following trigger example, only events with the attribute `type: dev.knative.samples.helloworld` are sent to the event sink: diff --git a/modules/kn-trigger-list.adoc b/modules/kn-trigger-list.adoc index d8b2d65dd0..263aa3911a 100644 --- a/modules/kn-trigger-list.adoc +++ b/modules/kn-trigger-list.adoc @@ -6,7 +6,7 @@ [id="kn-trigger-list_{context}"] = Listing triggers by using the Knative CLI -Using the `kn` CLI to list triggers provides a streamlined and intuitive user interface. You can use the `kn trigger list` command to list existing triggers in your cluster. +Using the Knative (`kn`) CLI to list triggers provides a streamlined and intuitive user interface. You can use the `kn trigger list` command to list existing triggers in your cluster. .Prerequisites diff --git a/modules/kn-trigger-update.adoc b/modules/kn-trigger-update.adoc index 83b9d8bb5f..7a886ddff8 100644 --- a/modules/kn-trigger-update.adoc +++ b/modules/kn-trigger-update.adoc @@ -6,7 +6,7 @@ [id="kn-trigger-update_{context}"] = Updating a trigger by using the Knative CLI -Using the `kn` CLI to update triggers provides a streamlined and intuitive user interface. You can use the `kn trigger update` command with certain flags to update attributes for a trigger. +Using the Knative (`kn`) CLI to update triggers provides a streamlined and intuitive user interface. You can use the `kn trigger update` command with certain flags to update attributes for a trigger. .Prerequisites diff --git a/modules/serverless-blue-green-deploy.adoc b/modules/serverless-blue-green-deploy.adoc index 2aa3d3c924..c107fdf1f5 100644 --- a/modules/serverless-blue-green-deploy.adoc +++ b/modules/serverless-blue-green-deploy.adoc @@ -55,7 +55,7 @@ spec: $ oc get ksvc ---- -. Deploy a second revision of your app by modifying at least one field in the `template` spec of the service and redeploying it. For example, you can modify the `image` of the service, or an `env` environment variable. You can redeploy the service by applying the service YAML file, or by using the `kn service update` command if you have installed the `kn` CLI. +. Deploy a second revision of your app by modifying at least one field in the `template` spec of the service and redeploying it. For example, you can modify the `image` of the service, or an `env` environment variable. You can redeploy the service by applying the service YAML file, or by using the `kn service update` command if you have installed the Knative (`kn`) CLI. . Find the name of the second, latest revision that was created when you redeployed the service, by running the command: + diff --git a/modules/serverless-create-broker-kn.adoc b/modules/serverless-create-broker-kn.adoc index 25ed1150c2..c608709e4d 100644 --- a/modules/serverless-create-broker-kn.adoc +++ b/modules/serverless-create-broker-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-create-broker-kn_{context}"] = Creating a broker by using the Knative CLI -Brokers can be used in combination with triggers to deliver events from an event source to an event sink. Using the `kn` CLI to create brokers provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the `kn broker create` command to create a broker by using the `kn` CLI. +Brokers can be used in combination with triggers to deliver events from an event source to an event sink. Using the Knative (`kn`) CLI to create brokers provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the `kn broker create` command to create a broker. .Prerequisites diff --git a/modules/serverless-create-channel-kn.adoc b/modules/serverless-create-channel-kn.adoc index dfa28da811..c1562cd7ad 100644 --- a/modules/serverless-create-channel-kn.adoc +++ b/modules/serverless-create-channel-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-create-channel-kn_{context}"] = Creating a channel by using the Knative CLI -Using the `kn` CLI to create channels provides a more streamlined and intuitive user interface than modifying YAML files directly. You can use the `kn channel create` command to create a channel by using the `kn` CLI. +Using the Knative (`kn`) CLI to create channels provides a more streamlined and intuitive user interface than modifying YAML files directly. You can use the `kn channel create` command to create a channel. .Prerequisites diff --git a/modules/serverless-create-domain-mapping-kn.adoc b/modules/serverless-create-domain-mapping-kn.adoc index b2aa3df27d..817738e96a 100644 --- a/modules/serverless-create-domain-mapping-kn.adoc +++ b/modules/serverless-create-domain-mapping-kn.adoc @@ -18,7 +18,7 @@ You can customize the domain for your Knative service by mapping a custom domain ==== Your custom domain must point to the DNS of the {product-title} cluster. ==== -* You have installed the `kn` CLI tool. +* You have installed the Knative (`kn`) CLI. * You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in {product-title}. .Procedure diff --git a/modules/serverless-create-func-kn.adoc b/modules/serverless-create-func-kn.adoc index 8fd4e6cecc..68e6f3e5ba 100644 --- a/modules/serverless-create-func-kn.adoc +++ b/modules/serverless-create-func-kn.adoc @@ -7,14 +7,12 @@ [id="serverless-create-func-kn_{context}"] = Creating functions -You can create a basic serverless function using the `kn` CLI. - -You can specify the path, runtime, template, and repository with the template as flags on the command line, or use the `-c` flag to start the interactive experience in the terminal. +Before you can build and deploy a function, you must create it by using the the Knative (`kn`) CLI. You can specify the path, runtime, template, and image registry as flags on the command line, or use the `-c` flag to start the interactive experience in the terminal. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. .Procedure diff --git a/modules/serverless-create-kn-trigger.adoc b/modules/serverless-create-kn-trigger.adoc index f341b6aa0c..763ac44122 100644 --- a/modules/serverless-create-kn-trigger.adoc +++ b/modules/serverless-create-kn-trigger.adoc @@ -6,7 +6,7 @@ [id="serverless-create-kn-trigger_{context}"] = Creating a trigger by using the Knative CLI -Using the `kn` CLI to create triggers provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the `kn trigger create` command to create a trigger by using the `kn` CLI. +Using the Knative (`kn`) CLI to create triggers provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the `kn trigger create` command to create a trigger. .Prerequisites diff --git a/modules/serverless-create-traffic-split-kn.adoc b/modules/serverless-create-traffic-split-kn.adoc index 3c645ef43d..2210567f60 100644 --- a/modules/serverless-create-traffic-split-kn.adoc +++ b/modules/serverless-create-traffic-split-kn.adoc @@ -6,12 +6,12 @@ [id="serverless-create-traffic-split-kn_{context}"] = Creating a traffic split by using the Knative CLI -Using the `kn` CLI to create traffic splits provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the `kn service update` command to split traffic between revisions of a service. +Using the Knative (`kn`) CLI to create traffic splits provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the `kn service update` command to split traffic between revisions of a service. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on your cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a Knative service. .Procedure diff --git a/modules/serverless-creating-subscriptions-kn.adoc b/modules/serverless-creating-subscriptions-kn.adoc index a783bb7685..845cf013de 100644 --- a/modules/serverless-creating-subscriptions-kn.adoc +++ b/modules/serverless-creating-subscriptions-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-creating-subscriptions-kn_{context}"] = Creating a subscription by using the Knative CLI -After you have created a channel and an event sink, you can create a subscription to enable event delivery. Using the `kn` CLI to create subscriptions provides a more streamlined and intuitive user interface than modifying YAML files directly. You can use the `kn subscription create` command as well as the appropriate flags to create a subscription by using the `kn` CLI. +After you have created a channel and an event sink, you can create a subscription to enable event delivery. Using the Knative (`kn`) CLI to create subscriptions provides a more streamlined and intuitive user interface than modifying YAML files directly. You can use the `kn subscription create` command with the appropriate flags to create a subscription. .Prerequisites diff --git a/modules/serverless-customize-labels-annotations-routes.adoc b/modules/serverless-customize-labels-annotations-routes.adoc index 6ab7d32936..01e5b18d4a 100644 --- a/modules/serverless-customize-labels-annotations-routes.adoc +++ b/modules/serverless-customize-labels-annotations-routes.adoc @@ -31,7 +31,7 @@ metadata: : ... ---- -** To create a service by using the `kn` CLI, enter: +** To create a service by using the Knative (`kn`) CLI, enter: + .Example service created by using a `kn` command [source,terminal] diff --git a/modules/serverless-describe-broker-kn.adoc b/modules/serverless-describe-broker-kn.adoc index b46b5bf46c..0e4a6c71e5 100644 --- a/modules/serverless-describe-broker-kn.adoc +++ b/modules/serverless-describe-broker-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-describe-broker-kn_{context}"] = Describing an existing broker by using the Knative CLI -Using the `kn` CLI to describe brokers provides a streamlined and intuitive user interface. You can use the `kn broker describe` command to print information about existing brokers in your cluster by using the `kn` CLI. +Using the Knative (`kn`) CLI to describe brokers provides a streamlined and intuitive user interface. You can use the `kn broker describe` command to print information about existing brokers in your cluster by using the Knative CLI. .Prerequisites diff --git a/modules/serverless-describe-subs-kn.adoc b/modules/serverless-describe-subs-kn.adoc index a25682b39f..2c871d5676 100644 --- a/modules/serverless-describe-subs-kn.adoc +++ b/modules/serverless-describe-subs-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-describe-subs-kn_{context}"] = Describing subscriptions by using the Knative CLI -You can use the `kn subscription describe` command to print information about a subscription in the terminal by using the `kn` CLI. Using the `kn` CLI to describe subscriptions provides a more streamlined and intuitive user interface than viewing YAML files directly. +You can use the `kn subscription describe` command to print information about a subscription in the terminal by using the Knative (`kn`) CLI. Using the Knative CLI to describe subscriptions provides a more streamlined and intuitive user interface than viewing YAML files directly. .Prerequisites diff --git a/modules/serverless-functions-adding-annotations.adoc b/modules/serverless-functions-adding-annotations.adoc index 9c79c38287..5bd19342d3 100644 --- a/modules/serverless-functions-adding-annotations.adoc +++ b/modules/serverless-functions-adding-annotations.adoc @@ -6,12 +6,12 @@ [id="serverless-functions-adding-annotations_{context}"] = Adding annotations to a function -You can use the following procedure to add annotations to a function. +You can add annotations to a function. Similar to a label, an annotation is defined as a key-value map. Annotations are useful, for example, for providing metadata about a function, such as the function's author. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function. .Procedure diff --git a/modules/serverless-functions-all-values-in-configmap-to-env-variables.adoc b/modules/serverless-functions-all-values-in-configmap-to-env-variables.adoc index d2f00cbc7e..d6e2b018ac 100644 --- a/modules/serverless-functions-all-values-in-configmap-to-env-variables.adoc +++ b/modules/serverless-functions-all-values-in-configmap-to-env-variables.adoc @@ -5,12 +5,12 @@ [id="serverless-functions-all-values-in-configmap-to-env-variables_{context}"] = Setting environment variables from all values defined in a config map -You can use the following procedure to set an environment variable from all values defined in a config map. +You can set an environment variable from all values defined in a config map. Values previously stored in a config map can then be accessed as environment variables by the function at runtime. This can be useful for simultaneously getting access to a collection of values stored in a config map, for example, a set of data pertaining to a user. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function. .Procedure @@ -29,5 +29,17 @@ envs: - value: '{{ configMap:myconfigmap }}' <1> ---- <1> Substitute `myconfigmap` with the name of the target config map. ++ +For example, to access all user data that is stored in `userdetailsmap`, use the following YAML: ++ +[source,yaml] +---- +name: test +namespace: "" +runtime: go +... +envs: +- value: '{{ configMap:userdetailsmap }}' +---- . Save the file. diff --git a/modules/serverless-functions-all-values-in-secret-to-env-variables.adoc b/modules/serverless-functions-all-values-in-secret-to-env-variables.adoc index df650fad16..98e3befef8 100644 --- a/modules/serverless-functions-all-values-in-secret-to-env-variables.adoc +++ b/modules/serverless-functions-all-values-in-secret-to-env-variables.adoc @@ -6,12 +6,12 @@ [id="serverless-functions-all-values-in-secret-to-env-variables_{context}"] = Setting environment variables from all values defined in a secret -You can use the following procedure to set an environment variable from all values defined in a secret. +You can set an environment variable from all values defined in a secret. Values previously stored in a secret can then be accessed as environment variables by the function at runtime. This can be useful for simultaneously getting access to a collection of values stored in a secret, for example, a set of data pertaining to a user. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function. .Procedure @@ -30,5 +30,17 @@ envs: - value: '{{ secret:mysecret }}' <1> ---- <1> Substitute `mysecret` with the name of the target secret. ++ +For example, to access all user data that is stored in `userdetailssecret`, use the following YAML: ++ +[source,yaml] +---- +name: test +namespace: "" +runtime: go +... +envs: +- value: '{{ configMap:userdetailssecret }}' +---- . Save the configuration. diff --git a/modules/serverless-functions-func-yaml-environment-variables.adoc b/modules/serverless-functions-func-yaml-environment-variables.adoc index fedf2ecb37..5768355555 100644 --- a/modules/serverless-functions-func-yaml-environment-variables.adoc +++ b/modules/serverless-functions-func-yaml-environment-variables.adoc @@ -6,9 +6,12 @@ [id="serverless-functions-func-yaml-environment-variables_{context}"] = Referencing local environment variables from func.yaml fields -In the `envs` field in the `func.yaml`, you can put a reference to an environment variable available in the local environment. This can be useful for avoiding storing sensitive information, such as an API key in the function configuration. +If you want to avoid storing sensitive information such as an API key in the function configuration, you can add a reference to an environment variable available in the local environment. You can do this by modifying the `envs` field in the `func.yaml` file. -// no prereqs? +.Prerequisites + +* You need to have the function project created. +* The local environment needs to contain the variable that you want to reference. .Procedure diff --git a/modules/serverless-functions-key-value-in-configmap-to-env-variable.adoc b/modules/serverless-functions-key-value-in-configmap-to-env-variable.adoc index f5b1cc5635..5d65221c62 100644 --- a/modules/serverless-functions-key-value-in-configmap-to-env-variable.adoc +++ b/modules/serverless-functions-key-value-in-configmap-to-env-variable.adoc @@ -6,12 +6,12 @@ [id="serverless-functions-key-value-in-configmap-to-env-variable_{context}"] = Setting environment variable from a key value defined in a config map -You can use the following procedure to set an environment variable from a key value defined as a config map. +You can set an environment variable from a key value defined as a config map. A value previously stored in a config map can then be accessed as an environment variable by the function at runtime. This can be useful for getting access to a value stored in a config map, such as the ID of a user. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function. .Procedure @@ -34,5 +34,17 @@ envs: * Substitute `EXAMPLE` with the name of the environment variable. * Substitute `myconfigmap` with the name of the target config map. * Substitute `key` with the key mapped to the target value. ++ +For example, to access the user ID that is stored in `userdetailsmap`, use the following YAML: ++ +[source,yaml] +---- +name: test +namespace: "" +runtime: go +... +envs: +- value: '{{ configMap:userdetailsmap:userid }}' +---- . Save the configuration. diff --git a/modules/serverless-functions-key-value-in-secret-to-env-variable.adoc b/modules/serverless-functions-key-value-in-secret-to-env-variable.adoc index 4c719c5ccc..5a648d5a35 100644 --- a/modules/serverless-functions-key-value-in-secret-to-env-variable.adoc +++ b/modules/serverless-functions-key-value-in-secret-to-env-variable.adoc @@ -6,12 +6,12 @@ [id="serverless-functions-key-value-in-secret-to-env-variable_{context}"] = Setting environment variable from a key value defined in a secret -You can use the following procedure to set an environment variable from a key value defined as a secret. +You can set an environment variable from a key value defined as a secret. A value previously stored in a secret can then be accessed as an environment variable by the function at runtime. This can be useful for getting access to a value stored in a secret, such as the ID of a user. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function. .Procedure @@ -34,5 +34,17 @@ envs: * Substitute `EXAMPLE` with the name of the environment variable. * Substitute `mysecret` with the name of the target secret. * Substitute `key` with the key mapped to the target value. ++ +For example, to access the user ID that is stored in `userdetailssecret`, use the following YAML: ++ +[source,yaml] +---- +name: test +namespace: "" +runtime: go +... +envs: +- value: '{{ configMap:userdetailssecret:userid }}' +---- . Save the configuration. diff --git a/modules/serverless-functions-mounting-configmap-as-volume.adoc b/modules/serverless-functions-mounting-configmap-as-volume.adoc index 1644f1c32e..b281be4cb4 100644 --- a/modules/serverless-functions-mounting-configmap-as-volume.adoc +++ b/modules/serverless-functions-mounting-configmap-as-volume.adoc @@ -6,12 +6,12 @@ [id="serverless-functions-mounting-configmap-as-volume_{context}"] = Mounting a config map as a volume -You can use the following procedure to mount a config map as a volume. +You can mount a config map as a volume. Once a config map is mounted, you can access it from the function as a regular file. This enables you to store on the cluster data needed by the function, for example, a list of URIs that need to be accessed by the function. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function. .Procedure @@ -33,5 +33,18 @@ volumes: + * Substitute `myconfigmap` with the name of the target config map. * Substitute `/workspace/configmap` with the path where you want to mount the config map. ++ +For example, to mount the `addresses` config map, use the following YAML: ++ +[source,yaml] +---- +name: test +namespace: "" +runtime: go +... +volumes: +- configMap: addresses + path: /workspace/configmap-addresses +---- . Save the configuration. diff --git a/modules/serverless-functions-mounting-secret-as-volume.adoc b/modules/serverless-functions-mounting-secret-as-volume.adoc index 6389918406..0383bf84c3 100644 --- a/modules/serverless-functions-mounting-secret-as-volume.adoc +++ b/modules/serverless-functions-mounting-secret-as-volume.adoc @@ -6,12 +6,12 @@ [id="serverless-functions-mounting-secret-as-volume_{context}"] = Mounting a secret as a volume -You can use the following procedure to mount a secret as a volume. +You can mount a secret as a volume. Once a secret is mounted, you can access it from the function as a regular file. This enables you to store on the cluster data needed by the function, for example, a list of URIs that need to be accessed by the function. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function. .Procedure @@ -33,5 +33,18 @@ volumes: + * Substitute `mysecret` with the name of the target secret. * Substitute `/workspace/secret` with the path where you want to mount the secret. ++ +For example, to mount the `addresses` secret, use the following YAML: ++ +[source,yaml] +---- +name: test +namespace: "" +runtime: go +... +volumes: +- configMap: addresses + path: /workspace/secret-addresses +---- . Save the configuration. diff --git a/modules/serverless-functions-podman.adoc b/modules/serverless-functions-podman.adoc index a03b8bdef3..5d1cad75eb 100644 --- a/modules/serverless-functions-podman.adoc +++ b/modules/serverless-functions-podman.adoc @@ -4,10 +4,15 @@ :_content-type: PROCEDURE [id="serverless-functions-podman_{context}"] -= Using podman += Setting up podman -If you are using podman, you must run the following commands before getting started with {FunctionsProductName}: +To use advanced container management features, you might want to use podman with {FunctionsProductName}. To do so, you need to start the podman service and configure the Knative (`kn`) CLI to connect to it. +.Procedure + +// This step might no longer be needed in the future, when automatic +// podman startup is reliable. +// https://github.com/openshift/openshift-docs/pull/46660/files#r907310116 . Start the podman service that serves the Docker API on a UNIX socket at `${XDG_RUNTIME_DIR}/podman/podman.sock`: + [source,terminal] diff --git a/modules/serverless-functions-quarkus-return-value-types.adoc b/modules/serverless-functions-quarkus-return-value-types.adoc index eb6acd5053..72d4641dee 100644 --- a/modules/serverless-functions-quarkus-return-value-types.adoc +++ b/modules/serverless-functions-quarkus-return-value-types.adoc @@ -6,15 +6,9 @@ [id="serverless-functions-quarkus-return-value-types_{context}"] = Permitted types -The input and output types of a function can be any of the following: +The input and output of a function can be any of the `void`, `String`, or `byte[]` types. Additionally, they can be primitive types and their wrappers, for example, `int` and `Integer`. They can also be the following complex objects: Javabeans, maps, lists, arrays, and the special `CloudEvents` type. -* `void` -* `String` -* `byte[]` -* Primitive types and their wrappers (for example, `int` and `Integer`). -* A JavaBean, if its attributes are of types listed here. -* A map, list, or array of the types in this list. -* The special `CloudEvents` type, where the `` type parameter is of a type in this list. +Maps, lists, arrays, the `` type parameter of the `CloudEvents` type, and attributes of Javabeans can only be of types listed here. .Example [source,java] diff --git a/modules/serverless-functions-secrets-configmaps-interactively.adoc b/modules/serverless-functions-secrets-configmaps-interactively.adoc index cf2f08edb8..1f1e0cc67d 100644 --- a/modules/serverless-functions-secrets-configmaps-interactively.adoc +++ b/modules/serverless-functions-secrets-configmaps-interactively.adoc @@ -6,12 +6,12 @@ [id="serverless-functions-secrets-configmaps-interactively_{context}"] = Modifying function access to secrets and config maps interactively -You can manage the secrets and config maps accessed by your function by using the `kn func config` interactive utility. +You can manage the secrets and config maps accessed by your function by using the `kn func config` interactive utility. The available operations include listing, adding, and removing values stored in config maps and secrets as environment variables, as well as listing, adding, and removing volumes. This functionality enables you to manage what data stored on the cluster is accessible by your function. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function. .Procedure diff --git a/modules/serverless-go-function-return-values.adoc b/modules/serverless-go-function-return-values.adoc index 106fc316ee..1498baba24 100644 --- a/modules/serverless-go-function-return-values.adoc +++ b/modules/serverless-go-function-return-values.adoc @@ -4,9 +4,9 @@ :_content-type: REFERENCE [id="serverless-go-function-return-values_{context}"] -= Golang function return values += Go function return values -HTTP triggered functions can set the response directly by using the Golang link:https://golang.org/pkg/net/http/#ResponseWriter[http.ResponseWriter]. +Functions triggered by HTTP requests can set the response directly. You can configure the function to do this by using the Go link:https://golang.org/pkg/net/http/#ResponseWriter[http.ResponseWriter]. .Example HTTP response [source,go] diff --git a/modules/serverless-go-template.adoc b/modules/serverless-go-template.adoc index 10a8320c51..5108d5e598 100644 --- a/modules/serverless-go-template.adoc +++ b/modules/serverless-go-template.adoc @@ -4,11 +4,11 @@ :_content-type: REFERENCE [id="serverless-go-template_{context}"] -= Golang function template structure += Go function template structure -When you create a Golang function using the `kn` CLI, the project directory looks like a typical Go project, with the exception of an additional `func.yaml` configuration file. +When you create a Go function using the Knative (`kn`) CLI, the project directory looks like a typical Go project. The only exception is the additional `func.yaml` configuration file, which is used for specifying the image. -Golang functions have few restrictions. The only requirements are that your project must be defined in a `function` module, and must export the function `Handle()`. +Go functions have few restrictions. The only requirements are that your project must be defined in a `function` module, and must export the function `Handle()`. Both `http` and `event` trigger functions have the same template structure: @@ -24,7 +24,7 @@ fn └── handle_test.go ---- <1> The `func.yaml` configuration file is used to determine the image name and registry. -<2> You can add any required dependencies to the `go.mod` file, which can include additional local Golang files. When the project is built for deployment, these dependencies are included in the resulting runtime container image. +<2> You can add any required dependencies to the `go.mod` file, which can include additional local Go files. When the project is built for deployment, these dependencies are included in the resulting runtime container image. + .Example of adding dependencies [source,terminal] diff --git a/modules/serverless-gpu-resources-kn.adoc b/modules/serverless-gpu-resources-kn.adoc index 5786278c1a..d67864813a 100644 --- a/modules/serverless-gpu-resources-kn.adoc +++ b/modules/serverless-gpu-resources-kn.adoc @@ -6,12 +6,12 @@ [id="serverless-gpu-resources-kn_{context}"] = Specifying GPU requirements for a service -After GPU resources are enabled for your {product-title} cluster, you can specify GPU requirements for a Knative service using the `kn` CLI. +After GPU resources are enabled for your {product-title} cluster, you can specify GPU requirements for a Knative service using the Knative (`kn`) CLI. .Prerequisites * The {ServerlessOperatorName}, Knative Serving and Knative Eventing are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * GPU resources are enabled for your {product-title} cluster. * You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in {product-title}. diff --git a/modules/serverless-invoking-go-functions-cloudevent.adoc b/modules/serverless-invoking-go-functions-cloudevent.adoc index 9258a33812..caf9b48518 100644 --- a/modules/serverless-invoking-go-functions-cloudevent.adoc +++ b/modules/serverless-invoking-go-functions-cloudevent.adoc @@ -6,9 +6,9 @@ [id="serverless-invoking-go-functions-cloudevent_{context}"] = Functions triggered by a cloud event -When an incoming cloud event is received, the event is invoked by the link:https://cloudevents.github.io/sdk-go/[CloudEvents Golang SDK] and the `Event` type as a parameter. +When an incoming cloud event is received, the event is invoked by the link:https://cloudevents.github.io/sdk-go/[CloudEvents Go SDK]. The invocation uses the `Event` type as a parameter. -You can leverage the Golang link:https://golang.org/pkg/context/[Context] as an optional parameter in the function contract, as shown in the list of supported function signatures: +You can leverage the Go link:https://golang.org/pkg/context/[Context] as an optional parameter in the function contract, as shown in the list of supported function signatures: .Supported function signatures [source,go] @@ -59,7 +59,7 @@ func Handle(ctx context.Context, event cloudevents.Event) (err error) { } ---- -Alternatively, a Golang `encoding/json` package could be used to access the cloud event directly as JSON in the form of a bytes array: +Alternatively, a Go `encoding/json` package could be used to access the cloud event directly as JSON in the form of a bytes array: [source,go] ---- diff --git a/modules/serverless-invoking-go-functions-http.adoc b/modules/serverless-invoking-go-functions-http.adoc index d03190b49d..f7c133701e 100644 --- a/modules/serverless-invoking-go-functions-http.adoc +++ b/modules/serverless-invoking-go-functions-http.adoc @@ -6,12 +6,7 @@ [id="serverless-invoking-go-functions-http_{context}"] = Functions triggered by an HTTP request -When an incoming HTTP request is received, your function is invoked with a standard Golang link:https://golang.org/pkg/context/[Context] as the first parameter, followed by two more parameters: - -* link:https://golang.org/pkg/net/http/#ResponseWriter[`http.ResponseWriter`] -* link:https://golang.org/pkg/net/http/#Request[`http.Request`] - -You can use standard Golang techniques to access the request, and set a proper HTTP response of your function. +When an incoming HTTP request is received, functions are invoked with a standard Go link:https://golang.org/pkg/context/[Context] as the first parameter, followed by the link:https://golang.org/pkg/net/http/#ResponseWriter[`http.ResponseWriter`] and link:https://golang.org/pkg/net/http/#Request[`http.Request`] parameters. You can use standard Go techniques to access the request, and set a corresponding HTTP response for your function. .Example HTTP response [source,go] diff --git a/modules/serverless-invoking-python-functions.adoc b/modules/serverless-invoking-python-functions.adoc index 14579ba053..1fd0cabd86 100644 --- a/modules/serverless-invoking-python-functions.adoc +++ b/modules/serverless-invoking-python-functions.adoc @@ -6,7 +6,9 @@ [id="serverless-invoking-python-functions_{context}"] = About invoking Python functions -Python functions can be invoked with a simple HTTP request. When an incoming request is received, functions are invoked with a `context` object as the first parameter. The `context` object is a Python class with two attributes: +Python functions can be invoked with a simple HTTP request. When an incoming request is received, functions are invoked with a `context` object as the first parameter. + +The `context` object is a Python class with two attributes: * The `request` attribute is always present, and contains the Flask `request` object. * The second attribute, `cloud_event`, is populated if the incoming request is a `CloudEvent` object. diff --git a/modules/serverless-kafka-source-kn.adoc b/modules/serverless-kafka-source-kn.adoc index 5cc6a8e256..30f5ba3206 100644 --- a/modules/serverless-kafka-source-kn.adoc +++ b/modules/serverless-kafka-source-kn.adoc @@ -7,7 +7,7 @@ [id="serverless-kafka-source-kn_{context}"] = Creating a Kafka event source by using the Knative CLI -You can use the `kn source kafka create` command to create a Kafka source by using the `kn` CLI. Using the `kn` CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly. +You can use the `kn source kafka create` command to create a Kafka source by using the Knative (`kn`) CLI. Using the Knative CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly. .Prerequisites diff --git a/modules/serverless-kn-config.adoc b/modules/serverless-kn-config.adoc index ca5b0db944..53136e360a 100644 --- a/modules/serverless-kn-config.adoc +++ b/modules/serverless-kn-config.adoc @@ -6,14 +6,14 @@ [id="serverless-kn-config_{context}"] = Customizing the Knative CLI -You can customize your `kn` CLI setup by creating a `config.yaml` configuration file. You can provide this configuration by using the `--config` flag, otherwise the configuration is picked up from a default location. The default configuration location conforms to the https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html[XDG Base Directory Specification], and is different for Unix systems and Windows systems. +You can customize your Knative (`kn`) CLI setup by creating a `config.yaml` configuration file. You can provide this configuration by using the `--config` flag, otherwise the configuration is picked up from a default location. The default configuration location conforms to the https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html[XDG Base Directory Specification], and is different for Unix systems and Windows systems. For Unix systems: -* If the `XDG_CONFIG_HOME` environment variable is set, the default configuration location that the `kn` CLI looks for is `$XDG_CONFIG_HOME/kn`. -* If the `XDG_CONFIG_HOME` environment variable is not set, the `kn` CLI looks for the configuration in the home directory of the user at `$HOME/.config/kn/config.yaml`. +* If the `XDG_CONFIG_HOME` environment variable is set, the default configuration location that the Knative CLI looks for is `$XDG_CONFIG_HOME/kn`. +* If the `XDG_CONFIG_HOME` environment variable is not set, the Knative CLI looks for the configuration in the home directory of the user at `$HOME/.config/kn/config.yaml`. -For Windows systems, the default `kn` CLI configuration location is `%APPDATA%\kn`. +For Windows systems, the default Knative CLI configuration location is `%APPDATA%\kn`. .Example configuration file [source,yaml] @@ -28,8 +28,8 @@ eventing: version: v1 <6> resource: services <7> ---- -<1> Specifies whether the `kn` CLI should look for plug-ins in the `PATH` environment variable. This is a boolean configuration option. The default value is `false`. -<2> Specifies the directory where the `kn` CLI will look for plug-ins. The default path depends on the operating system, as described above. This can be any directory that is visible to the user. +<1> Specifies whether the Knative CLI should look for plug-ins in the `PATH` environment variable. This is a boolean configuration option. The default value is `false`. +<2> Specifies the directory where the Knative CLI will look for plug-ins. The default path depends on the operating system, as described above. This can be any directory that is visible to the user. <3> The `sink-mappings` spec defines the Kubernetes addressable resource that is used when you use the `--sink` flag with a `kn` CLI command. <4> The prefix you want to use to describe your sink. `svc` for a service, `channel`, and `broker` are predefined prefixes in `kn`. <5> The API group of the Kubernetes resource. diff --git a/modules/serverless-kn-containersource.adoc b/modules/serverless-kn-containersource.adoc index 6b6202b7f7..d551f58a22 100644 --- a/modules/serverless-kn-containersource.adoc +++ b/modules/serverless-kn-containersource.adoc @@ -8,7 +8,7 @@ = Creating and managing container sources by using the Knative CLI // needs to be revised as separate procedure modules; out of scope for this PR -You can use the `kn source container` commands to create and manage container sources by using the `kn` CLI. Using the `kn` CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly. +You can use the `kn source container` commands to create and manage container sources by using the Knative (`kn`) CLI. Using the Knative CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly. .Create a container source [source,terminal] diff --git a/modules/serverless-list-broker-kn.adoc b/modules/serverless-list-broker-kn.adoc index 13d659e3c4..af84bc3545 100644 --- a/modules/serverless-list-broker-kn.adoc +++ b/modules/serverless-list-broker-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-list-broker-kn_{context}"] = Listing existing brokers by using the Knative CLI -Using the `kn` CLI to list brokers provides a streamlined and intuitive user interface. You can use the `kn broker list` command to list existing brokers in your cluster by using the `kn` CLI. +Using the Knative (`kn`) CLI to list brokers provides a streamlined and intuitive user interface. You can use the `kn broker list` command to list existing brokers in your cluster by using the Knative CLI. .Prerequisites diff --git a/modules/serverless-list-source-types-kn.adoc b/modules/serverless-list-source-types-kn.adoc index d8add176cc..78dbbcf4fc 100644 --- a/modules/serverless-list-source-types-kn.adoc +++ b/modules/serverless-list-source-types-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-list-source-types-kn_{context}"] = Listing available event source types by using the Knative CLI -Using the `kn` CLI provides a streamlined and intuitive user interface to view available event source types on your cluster. You can list event source types that can be created and used on your cluster by using the `kn source list-types` CLI command. +Using the Knative (`kn`) CLI provides a streamlined and intuitive user interface to view available event source types on your cluster. You can list event source types that can be created and used on your cluster by using the `kn source list-types` CLI command. .Prerequisites diff --git a/modules/serverless-list-source.adoc b/modules/serverless-list-source.adoc index f5d4b712e4..79bf913368 100644 --- a/modules/serverless-list-source.adoc +++ b/modules/serverless-list-source.adoc @@ -6,7 +6,7 @@ [id="serverless-list-source_{context}"] = Listing available event sources by using the Knative CLI -Using the `kn` CLI provides a streamlined and intuitive user interface to view existing event sources on your cluster. You can list existing event sources by using the `kn source list` command. +Using the Knative (`kn`) CLI provides a streamlined and intuitive user interface to view existing event sources on your cluster. You can list existing event sources by using the `kn source list` command. .Prerequisites diff --git a/modules/serverless-list-subs-kn.adoc b/modules/serverless-list-subs-kn.adoc index 480db9a4b8..d260c36c2c 100644 --- a/modules/serverless-list-subs-kn.adoc +++ b/modules/serverless-list-subs-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-list-subs-kn_{context}"] = Listing subscriptions by using the Knative CLI -You can use the `kn subscription list` command to list existing subscriptions on your cluster by using the `kn` CLI. Using the `kn` CLI to list subscriptions provides a streamlined and intuitive user interface. +You can use the `kn subscription list` command to list existing subscriptions on your cluster by using the Knative (`kn`) CLI. Using the Knative CLI to list subscriptions provides a streamlined and intuitive user interface. .Prerequisites diff --git a/modules/serverless-manage-domain-mapping-kn.adoc b/modules/serverless-manage-domain-mapping-kn.adoc index 351f0f7e5c..04ee9b2536 100644 --- a/modules/serverless-manage-domain-mapping-kn.adoc +++ b/modules/serverless-manage-domain-mapping-kn.adoc @@ -6,13 +6,13 @@ [id="serverless-manage-domain-mapping-kn_{context}"] = Managing custom domain mappings by using the Knative CLI -After you have created a `DomainMapping` custom resource (CR), you can list existing CRs, view information about an existing CR, update CRs, or delete CRs by using the `kn` CLI. +After you have created a `DomainMapping` custom resource (CR), you can list existing CRs, view information about an existing CR, update CRs, or delete CRs by using the Knative (`kn`) CLI. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on your cluster. * You have created at least one `DomainMapping` CR. -* You have installed the `kn` CLI tool. +* You have installed the Knative (`kn`) CLI tool. * You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in {product-title}. .Procedure diff --git a/modules/serverless-nodejs-context-object-reference.adoc b/modules/serverless-nodejs-context-object-reference.adoc index bede3511aa..42f95b4db0 100644 --- a/modules/serverless-nodejs-context-object-reference.adoc +++ b/modules/serverless-nodejs-context-object-reference.adoc @@ -6,7 +6,7 @@ [id="serverless-nodejs-context-object-reference_{context}"] = Node.js context object reference -The `context` object has several properties that can be accessed by the function developer. +The `context` object has several properties that can be accessed by the function developer. Accessing these properties can provide information about HTTP requests and write output to the cluster logs. [id="serverless-nodejs-context-object-reference-log_{context}"] == log diff --git a/modules/serverless-nodejs-functions-context-objects.adoc b/modules/serverless-nodejs-functions-context-objects.adoc index 1d9aee579f..cbfed0fc73 100644 --- a/modules/serverless-nodejs-functions-context-objects.adoc +++ b/modules/serverless-nodejs-functions-context-objects.adoc @@ -6,7 +6,7 @@ [id="serverless-nodejs-functions-context-objects_{context}"] = Node.js context objects -Functions are invoked by providing a `context` object as the first parameter. +Functions are invoked by providing a `context` object as the first parameter. This object provides access to the incoming HTTP request information. .Example context object [source,javascript] @@ -14,7 +14,7 @@ Functions are invoked by providing a `context` object as the first parameter. function handle(context, data) ---- -This object provides access to the incoming HTTP request information, including the HTTP request method, any query strings or headers sent with the request, the HTTP version, and the request body. Incoming requests that contain a CloudEvent attach the incoming instance of the CloudEvent to the context object so that it can be accessed by using `context.cloudevent`. +This information includes the HTTP request method, any query strings or headers sent with the request, the HTTP version, and the request body. Incoming requests that contain a `CloudEvent` attach the incoming instance of the CloudEvent to the context object so that it can be accessed by using `context.cloudevent`. [id="serverless-nodejs-functions-context-objects-methods_{context}"] == Context object methods diff --git a/modules/serverless-nodejs-template.adoc b/modules/serverless-nodejs-template.adoc index 3e2fc4fef8..6d0a7b8603 100644 --- a/modules/serverless-nodejs-template.adoc +++ b/modules/serverless-nodejs-template.adoc @@ -6,7 +6,7 @@ [id="serverless-nodejs-template_{context}"] = Node.js function template structure -When you create a Node.js function using the `kn` CLI, the project directory looks like a typical Node.js project, with the exception of an additional `func.yaml` configuration file. +When you create a Node.js function using the Knative (`kn`) CLI, the project directory looks like a typical Node.js project. The only exception is the additional `func.yaml` file, which is used to configure the function. Both `http` and `event` trigger functions have the same template structure: diff --git a/modules/serverless-pingsource-kn.adoc b/modules/serverless-pingsource-kn.adoc index d416786d2f..8e747bb634 100644 --- a/modules/serverless-pingsource-kn.adoc +++ b/modules/serverless-pingsource-kn.adoc @@ -7,7 +7,7 @@ [id="serverless-pingsource-kn_{context}"] = Creating a ping source by using the Knative CLI -You can use the `kn source ping create` command to create a ping source by using the `kn` CLI. Using the `kn` CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly. +You can use the `kn source ping create` command to create a ping source by using the Knative (`kn`) CLI. Using the Knative CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly. .Prerequisites diff --git a/modules/serverless-python-function-return-values.adoc b/modules/serverless-python-function-return-values.adoc index a8ee88ceaf..63dba4e927 100644 --- a/modules/serverless-python-function-return-values.adoc +++ b/modules/serverless-python-function-return-values.adoc @@ -6,7 +6,7 @@ [id="serverless-python-function-return-values_{context}"] = Python function return values -Functions can return any value supported by link:https://flask.palletsprojects.com/en/1.1.x/quickstart/#about-responses[Flask] because the invocation framework proxies these values directly to the Flask server. +Functions can return any value supported by link:https://flask.palletsprojects.com/en/1.1.x/quickstart/#about-responses[Flask]. This is because the invocation framework proxies these values directly to the Flask server. .Example [source,python] diff --git a/modules/serverless-python-template.adoc b/modules/serverless-python-template.adoc index 62f1952831..614df54d27 100644 --- a/modules/serverless-python-template.adoc +++ b/modules/serverless-python-template.adoc @@ -6,9 +6,7 @@ [id="serverless-python-template_{context}"] = Python function template structure -When you create a Python function by using the `kn` CLI, the project directory looks similar to a typical Python project. - -Python functions have very few restrictions. The only requirements are that your project contains a `func.py` file that contains a `main()` function, and a `func.yaml` configuration file. +When you create a Python function by using the Knative (`kn`) CLI, the project directory looks similar to a typical Python project. Python functions have very few restrictions. The only requirements are that your project contains a `func.py` file that contains a `main()` function, and a `func.yaml` configuration file. Developers are not restricted to the dependencies provided in the template `requirements.txt` file. Additional dependencies can be added as they would be in any other Python project. When the project is built for deployment, these dependencies will be included in the created runtime container image. diff --git a/modules/serverless-quarkus-function-return-values.adoc b/modules/serverless-quarkus-function-return-values.adoc index 30982f8be7..031b88d132 100644 --- a/modules/serverless-quarkus-function-return-values.adoc +++ b/modules/serverless-quarkus-function-return-values.adoc @@ -6,11 +6,7 @@ [id="serverless-quarkus-function-return-values_{context}"] = Quarkus function return values -Functions can return an instance of: - -* Any type from the list of permitted types. - -* The `Uni` type, where the `` type parameter can be of any type from the permitted types. +Functions can return an instance of any type from the list of permitted types. Alternatively, they can return the `Uni` type, where the `` type parameter can be of any type from the permitted types. The `Uni` type is useful if a function calls asynchronous APIs, because the returned object is serialized in the same format as the received object. For example: diff --git a/modules/serverless-quarkus-template.adoc b/modules/serverless-quarkus-template.adoc index 27eb86ba09..9d2a0f24d7 100644 --- a/modules/serverless-quarkus-template.adoc +++ b/modules/serverless-quarkus-template.adoc @@ -6,7 +6,7 @@ [id="serverless-quarkus-template_{context}"] = Quarkus function template structure -When you create a Quarkus function by using the `kn` CLI, the project directory looks similar to a typical Maven project. +When you create a Quarkus function by using the Knative (`kn`) CLI, the project directory looks similar to a typical Maven project. Additionally, the project contains the `func.yaml` file, which is used for configuring the function. Both `http` and `event` trigger functions have the same template structure: diff --git a/modules/serverless-rn-1-18-0.adoc b/modules/serverless-rn-1-18-0.adoc index edb83ea6c7..39970f4e8d 100644 --- a/modules/serverless-rn-1-18-0.adoc +++ b/modules/serverless-rn-1-18-0.adoc @@ -14,7 +14,7 @@ * {ServerlessProductName} now uses Knative Serving 0.24.0. * {ServerlessProductName} now uses Knative Eventing 0.24.0. * {ServerlessProductName} now uses Kourier 0.24.0. -* {ServerlessProductName} now uses Knative `kn` CLI 0.24.0. +* {ServerlessProductName} now uses Knative (`kn`) CLI 0.24.0. * {ServerlessProductName} now uses Knative Kafka 0.24.7. * The `kn func` CLI plug-in now uses `func` 0.18.0. * In the upcoming {ServerlessProductName} 1.19.0 release, the URL scheme of external routes will default to HTTPS for enhanced security. diff --git a/modules/serverless-rn-1-19-0.adoc b/modules/serverless-rn-1-19-0.adoc index f445dd8ce2..bb25fe9036 100644 --- a/modules/serverless-rn-1-19-0.adoc +++ b/modules/serverless-rn-1-19-0.adoc @@ -14,7 +14,7 @@ * {ServerlessProductName} now uses Knative Serving 0.25. * {ServerlessProductName} now uses Knative Eventing 0.25. * {ServerlessProductName} now uses Kourier 0.25. -* {ServerlessProductName} now uses Knative `kn` CLI 0.25. +* {ServerlessProductName} now uses Knative (`kn`) CLI 0.25. * {ServerlessProductName} now uses Knative Kafka 0.25. * The `kn func` CLI plug-in now uses `func` 0.19. diff --git a/modules/serverless-rn-1-20-0.adoc b/modules/serverless-rn-1-20-0.adoc index 8048f509f9..9ffe8aa3dd 100644 --- a/modules/serverless-rn-1-20-0.adoc +++ b/modules/serverless-rn-1-20-0.adoc @@ -14,7 +14,7 @@ * {ServerlessProductName} now uses Knative Serving 0.26. * {ServerlessProductName} now uses Knative Eventing 0.26. * {ServerlessProductName} now uses Kourier 0.26. -* {ServerlessProductName} now uses Knative `kn` CLI 0.26. +* {ServerlessProductName} now uses Knative (`kn`) CLI 0.26. * {ServerlessProductName} now uses Knative Kafka 0.26. * The `kn func` CLI plug-in now uses `func` 0.20. diff --git a/modules/serverless-rn-1-21-0.adoc b/modules/serverless-rn-1-21-0.adoc index 7885e1227b..ba4af30d5e 100644 --- a/modules/serverless-rn-1-21-0.adoc +++ b/modules/serverless-rn-1-21-0.adoc @@ -14,7 +14,7 @@ * {ServerlessProductName} now uses Knative Serving 1.0 * {ServerlessProductName} now uses Knative Eventing 1.0. * {ServerlessProductName} now uses Kourier 1.0. -* {ServerlessProductName} now uses Knative `kn` CLI 1.0. +* {ServerlessProductName} now uses Knative (`kn`) CLI 1.0. * {ServerlessProductName} now uses Knative Kafka 1.0. * The `kn func` CLI plug-in now uses `func` 0.21. * The Kafka sink is now available as a Technology Preview. diff --git a/modules/serverless-rn-1-22-0.adoc b/modules/serverless-rn-1-22-0.adoc index 8eac55e8b9..5f845238d1 100644 --- a/modules/serverless-rn-1-22-0.adoc +++ b/modules/serverless-rn-1-22-0.adoc @@ -14,7 +14,7 @@ * {ServerlessProductName} now uses Knative Serving 1.1. * {ServerlessProductName} now uses Knative Eventing 1.1. * {ServerlessProductName} now uses Kourier 1.1. -* {ServerlessProductName} now uses Knative `kn` CLI 1.1. +* {ServerlessProductName} now uses Knative (`kn`) CLI 1.1. * {ServerlessProductName} now uses Knative Kafka 1.1. * The `kn func` CLI plug-in now uses `func` 0.23. * Init containers support for Knative services is now available as a Technology Preview. diff --git a/modules/serverless-rn-1-23-0.adoc b/modules/serverless-rn-1-23-0.adoc index e59db1aabe..0f5b3a0d20 100644 --- a/modules/serverless-rn-1-23-0.adoc +++ b/modules/serverless-rn-1-23-0.adoc @@ -14,7 +14,7 @@ * {ServerlessProductName} now uses Knative Serving 1.2. * {ServerlessProductName} now uses Knative Eventing 1.2. * {ServerlessProductName} now uses Kourier 1.2. -* {ServerlessProductName} now uses Knative `kn` CLI 1.2. +* {ServerlessProductName} now uses Knative (`kn`) CLI 1.2. * {ServerlessProductName} now uses Knative Kafka 1.2. * The `kn func` CLI plug-in now uses `func` 0.24. diff --git a/modules/serverless-rn-template-module.adoc b/modules/serverless-rn-template-module.adoc index 68270b3c5e..2b373d05d1 100644 --- a/modules/serverless-rn-template-module.adoc +++ b/modules/serverless-rn-template-module.adoc @@ -17,7 +17,7 @@ * {ServerlessProductName} now uses Knative Serving 0.x. * {ServerlessProductName} now uses Knative Eventing 0.x. * {ServerlessProductName} now uses Kourier 0.x. -* {ServerlessProductName} now uses Knative `kn` CLI 0.x. +* {ServerlessProductName} now uses Knative (`kn`) CLI 0.x. * {ServerlessProductName} now uses Knative Kafka 0.x. * The `kn func` CLI plug-in now uses `func` 0.x. diff --git a/modules/serverless-sinkbinding-kn.adoc b/modules/serverless-sinkbinding-kn.adoc index 066d3bc94e..c044add784 100644 --- a/modules/serverless-sinkbinding-kn.adoc +++ b/modules/serverless-sinkbinding-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-sinkbinding-kn_{context}"] = Creating a sink binding by using the Knative CLI -You can use the `kn source binding create` command to create a sink binding by using the `kn` CLI. Using the `kn` CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly. +You can use the `kn source binding create` command to create a sink binding by using the Knative (`kn`) CLI. Using the Knative CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly. .Prerequisites diff --git a/modules/serverless-testing-go-functions.adoc b/modules/serverless-testing-go-functions.adoc index 14c95b66dd..d0c67930c2 100644 --- a/modules/serverless-testing-go-functions.adoc +++ b/modules/serverless-testing-go-functions.adoc @@ -4,14 +4,14 @@ :_content-type: PROCEDURE [id="serverless-testing-go-functions_{context}"] -= Testing Golang functions += Testing Go functions -Golang functions can be tested locally on your computer. In the default project that is created when you create a function using `kn func create`, there is a `handle_test.go` file which contains some basic tests. These tests can be extended as needed. +Go functions can be tested locally on your computer. In the default project that is created when you create a function using `kn func create`, there is a `handle_test.go` file, which contains some basic tests. These tests can be extended as needed. .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function by using `kn func create`. .Procedure diff --git a/modules/serverless-testing-nodejs-functions.adoc b/modules/serverless-testing-nodejs-functions.adoc index d9798fd3aa..acd05417de 100644 --- a/modules/serverless-testing-nodejs-functions.adoc +++ b/modules/serverless-testing-nodejs-functions.adoc @@ -11,7 +11,7 @@ Node.js functions can be tested locally on your computer. In the default project .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function by using `kn func create`. .Procedure diff --git a/modules/serverless-testing-quarkus-functions.adoc b/modules/serverless-testing-quarkus-functions.adoc index 2363051031..f918527fc1 100644 --- a/modules/serverless-testing-quarkus-functions.adoc +++ b/modules/serverless-testing-quarkus-functions.adoc @@ -6,11 +6,12 @@ [id="serverless-testing-quarkus-functions_{context}"] = Testing Quarkus functions -You can test Quarkus functions locally on your computer by running the Maven tests that are included in the project template. +Quarkus functions can be tested locally on your computer. In the default project that is created when you create a function using `kn func create`, there is the `src/test/` directory, which contains basic Maven tests. These tests can be extended as needed. .Prerequisites * You have created a Quarkus function. +* You have installed the Knative (`kn`) CLI. .Procedure diff --git a/modules/serverless-testing-typescript-functions.adoc b/modules/serverless-testing-typescript-functions.adoc index a9955828a1..2dc1c91e78 100644 --- a/modules/serverless-testing-typescript-functions.adoc +++ b/modules/serverless-testing-typescript-functions.adoc @@ -11,7 +11,7 @@ TypeScript functions can be tested locally on your computer. In the default proj .Prerequisites * The {ServerlessOperatorName} and Knative Serving are installed on the cluster. -* You have installed the `kn` CLI. +* You have installed the Knative (`kn`) CLI. * You have created a function by using `kn func create`. .Procedure diff --git a/modules/serverless-traffic-splitting-flags-kn.adoc b/modules/serverless-traffic-splitting-flags-kn.adoc index 43a1808985..2d3046659c 100644 --- a/modules/serverless-traffic-splitting-flags-kn.adoc +++ b/modules/serverless-traffic-splitting-flags-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-traffic-splitting-flags-kn_{context}"] = Knative CLI traffic management flags -The `kn` CLI supports traffic operations on the traffic block of a service as part of the `kn service update` command. +The Knative (`kn`) CLI supports traffic operations on the traffic block of a service as part of the `kn service update` command. The following table displays a summary of traffic splitting flags, value formats, and the operation the flag performs. The *Repetition* column denotes whether repeating the particular value of flag is allowed in a `kn service update` command. diff --git a/modules/serverless-typescript-context-object-reference.adoc b/modules/serverless-typescript-context-object-reference.adoc index 445d56942b..aba0d57507 100644 --- a/modules/serverless-typescript-context-object-reference.adoc +++ b/modules/serverless-typescript-context-object-reference.adoc @@ -6,7 +6,7 @@ [id="serverless-typescript-context-object-reference_{context}"] = TypeScript context object reference -The `context` object has several properties that can be accessed by the function developer. +The `context` object has several properties that can be accessed by the function developer. Accessing these properties can provide information about incoming HTTP requests and write output to the cluster logs. [id="serverless-typescript-context-object-reference-log_{context}"] == log diff --git a/modules/serverless-typescript-functions-context-objects.adoc b/modules/serverless-typescript-functions-context-objects.adoc index 67b591bd2a..d1809206db 100644 --- a/modules/serverless-typescript-functions-context-objects.adoc +++ b/modules/serverless-typescript-functions-context-objects.adoc @@ -6,7 +6,7 @@ [id="serverless-typescript-functions-context-objects_{context}"] = TypeScript context objects -Functions are invoked with a `context` object as the first parameter. +To invoke a function, you provide a `context` object as the first parameter. Accessing properties of the `context` object can provide information about the incoming HTTP request. .Example context object [source,javascript] @@ -14,7 +14,7 @@ Functions are invoked with a `context` object as the first parameter. function handle(context:Context): string ---- -This object provides access to the incoming HTTP request information, including the HTTP request method, any query strings or headers sent with the request, the HTTP version, and the request body. Incoming requests that contain a CloudEvent attach the incoming instance of the CloudEvent to the context object so that it can be accessed by using `context.cloudevent`. +This information includes the HTTP request method, any query strings or headers sent with the request, the HTTP version, and the request body. Incoming requests that contain a `CloudEvent` attach the incoming instance of the CloudEvent to the context object so that it can be accessed by using `context.cloudevent`. [id="serverless-typescript-functions-context-objects-methods_{context}"] == Context object methods diff --git a/modules/serverless-typescript-template.adoc b/modules/serverless-typescript-template.adoc index a2c77c27d4..6c5da5f0c6 100644 --- a/modules/serverless-typescript-template.adoc +++ b/modules/serverless-typescript-template.adoc @@ -6,7 +6,7 @@ [id="serverless-typescript-template_{context}"] = TypeScript function template structure -When you create a TypeScript function using the `kn` CLI, the project directory looks like a typical TypeScript project with the exception of an additional `func.yaml` configuration file. +When you create a TypeScript function using the Knative (`kn`) CLI, the project directory looks like a typical TypeScript project. The only exception is the additional `func.yaml` file, which is used for configuring the function. Both `http` and `event` trigger functions have the same template structure: diff --git a/modules/serverless-update-subscriptions-kn.adoc b/modules/serverless-update-subscriptions-kn.adoc index e1055f77f7..eaee739181 100644 --- a/modules/serverless-update-subscriptions-kn.adoc +++ b/modules/serverless-update-subscriptions-kn.adoc @@ -6,7 +6,7 @@ [id="serverless-update-subscriptions-kn_{context}"] = Updating subscriptions by using the Knative CLI -You can use the `kn subscription update` command as well as the appropriate flags to update a subscription from the terminal by using the `kn` CLI. Using the `kn` CLI to update subscriptions provides a more streamlined and intuitive user interface than updating YAML files directly. +You can use the `kn subscription update` command as well as the appropriate flags to update a subscription from the terminal by using the Knative (`kn`) CLI. Using the Knative CLI to update subscriptions provides a more streamlined and intuitive user interface than updating YAML files directly. .Prerequisites diff --git a/serverless/cli_tools/kn-serving-ref.adoc b/serverless/cli_tools/kn-serving-ref.adoc index c149a4c2ee..1eed44e533 100644 --- a/serverless/cli_tools/kn-serving-ref.adoc +++ b/serverless/cli_tools/kn-serving-ref.adoc @@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -You can use the following `kn` CLI commands to complete Knative Serving tasks on the cluster. +You can use the following Knative (`kn`) CLI commands to complete Knative Serving tasks on the cluster. [id="kn-serving-ref-kn-service"] == kn service commands diff --git a/serverless/develop/serverless-applications.adoc b/serverless/develop/serverless-applications.adoc index 276c578e85..1ca40f9280 100644 --- a/serverless/develop/serverless-applications.adoc +++ b/serverless/develop/serverless-applications.adoc @@ -15,7 +15,7 @@ You can create a serverless application by using one of the following methods: ifdef::openshift-enterprise[] See xref:../../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications using the Developer perspective] for more information. endif::[] -* Create a Knative service by using the `kn` CLI. +* Create a Knative service by using the Knative (`kn`) CLI. * Create and apply a Knative `Service` object as a YAML file, by using the `oc` CLI. // create service using CLI diff --git a/serverless/develop/serverless-autoscaling-developer.adoc b/serverless/develop/serverless-autoscaling-developer.adoc index c035e9fe99..b4e8a85937 100644 --- a/serverless/develop/serverless-autoscaling-developer.adoc +++ b/serverless/develop/serverless-autoscaling-developer.adoc @@ -16,7 +16,7 @@ ifdef::openshift-dedicated,openshift-rosa[] Autoscaling settings for Knative services can be global settings that are configured by cluster or dedicated administrators, or per-revision settings that are configured for individual services. endif::[] -You can modify per-revision settings for your services by using the {product-title} web console, by modifying the YAML file for your service, or by using the `kn` CLI. +You can modify per-revision settings for your services by using the {product-title} web console, by modifying the YAML file for your service, or by using the Knative (`kn`) CLI. [NOTE] ==== diff --git a/serverless/develop/serverless-event-sinks.adoc b/serverless/develop/serverless-event-sinks.adoc index ed4f9ee39e..0c1e9d0d8e 100644 --- a/serverless/develop/serverless-event-sinks.adoc +++ b/serverless/develop/serverless-event-sinks.adoc @@ -17,7 +17,7 @@ include::modules/specifying-sink-flag-kn.adoc[leveloffset=+1] [TIP] ==== -You can configure which CRs can be used with the `--sink` flag for `kn` CLI commands by xref:../../serverless/cli_tools/advanced-kn-config.adoc#advanced-kn-config[Customizing `kn`]. +You can configure which CRs can be used with the `--sink` flag for Knative (`kn`) CLI commands by xref:../../serverless/cli_tools/advanced-kn-config.adoc#advanced-kn-config[Customizing `kn`]. ==== // Connect sinks to sources in ODC diff --git a/serverless/develop/serverless-listing-event-sources.adoc b/serverless/develop/serverless-listing-event-sources.adoc index 2389bff661..b13dcc26a2 100644 --- a/serverless/develop/serverless-listing-event-sources.adoc +++ b/serverless/develop/serverless-listing-event-sources.adoc @@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -It is possible to view a list of all event sources or event source types that exist or are available for use on your {product-title} cluster. You can use the `kn` CLI or the *Developer* perspective in the {product-title} web console to list available event sources or event source types. +It is possible to view a list of all event sources or event source types that exist or are available for use on your {product-title} cluster. You can use the Knative (`kn`) CLI or the *Developer* perspective in the {product-title} web console to list available event sources or event source types. include::modules/serverless-list-source-types-kn.adoc[leveloffset=+1] include::modules/serverless-list-source-types-odc.adoc[leveloffset=+1] diff --git a/serverless/develop/serverless-traffic-management.adoc b/serverless/develop/serverless-traffic-management.adoc index 4eb6c78d33..06d818a982 100644 --- a/serverless/develop/serverless-traffic-management.adoc +++ b/serverless/develop/serverless-traffic-management.adoc @@ -20,7 +20,7 @@ The revisions specified in a `traffic` spec can either be a fixed, named revisio The `traffic` spec can be modified by: * Editing the YAML of a `Service` object directly. -* Using the `kn` CLI `--traffic` flag. +* Using the Knative (`kn`) CLI `--traffic` flag. * Using the {product-title} web console. When you create a Knative service, it does not have any default `traffic` spec settings. diff --git a/serverless/develop/serverless-using-brokers.adoc b/serverless/develop/serverless-using-brokers.adoc index 0fc410c49b..a291bb993a 100644 --- a/serverless/develop/serverless-using-brokers.adoc +++ b/serverless/develop/serverless-using-brokers.adoc @@ -13,7 +13,7 @@ include::modules/serverless-broker-types.adoc[leveloffset=+1] [id="serverless-using-brokers-creating-brokers"] == Creating a broker that uses default settings -{ServerlessProductName} provides a `default` Knative broker that you can create by using the `kn` CLI. You can also create the `default` broker by adding the `eventing.knative.dev/injection: enabled` annotation to a trigger, or by adding the `eventing.knative.dev/injection=enabled` label to a namespace. +{ServerlessProductName} provides a `default` Knative broker that you can create by using the Knative (`kn`) CLI. You can also create the `default` broker by adding the `eventing.knative.dev/injection: enabled` annotation to a trigger, or by adding the `eventing.knative.dev/injection=enabled` label to a namespace. include::modules/serverless-create-broker-kn.adoc[leveloffset=+2] include::modules/serverless-creating-broker-annotation.adoc[leveloffset=+2] @@ -35,7 +35,7 @@ include::modules/serverless-kafka-broker-with-kafka-topic.adoc[leveloffset=+2] [id="serverless-using-brokers-managing-brokers"] == Managing brokers -The `kn` CLI provides commands that can be used to list, describe, update, and delete brokers. +The Knative (`kn`) CLI provides commands that can be used to list, describe, update, and delete brokers. include::modules/serverless-list-broker-kn.adoc[leveloffset=+2] include::modules/serverless-describe-broker-kn.adoc[leveloffset=+2] diff --git a/serverless/discover/knative-event-sources.adoc b/serverless/discover/knative-event-sources.adoc index 16cff82515..477fd40094 100644 --- a/serverless/discover/knative-event-sources.adoc +++ b/serverless/discover/knative-event-sources.adoc @@ -8,7 +8,7 @@ toc::[] A Knative _event source_ can be any Kubernetes object that generates or imports cloud events, and relays those events to another endpoint, known as a xref:../../serverless/develop/serverless-event-sinks.adoc#serverless-event-sinks[_sink_]. Sourcing events is critical to developing a distributed system that reacts to events. -You can create and manage Knative event sources by using the *Developer* perspective in the {product-title} web console, the `kn` CLI, or by applying YAML files. +You can create and manage Knative event sources by using the *Developer* perspective in the {product-title} web console, the Knative (`kn`) CLI, or by applying YAML files. Currently, {ServerlessProductName} supports the following event source types: diff --git a/serverless/discover/serverless-functions-about.adoc b/serverless/discover/serverless-functions-about.adoc index 1a96da6d00..aaa7c71c22 100644 --- a/serverless/discover/serverless-functions-about.adoc +++ b/serverless/discover/serverless-functions-about.adoc @@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -{FunctionsProductName} enables developers to create and deploy stateless, event-driven functions as a Knative service on {product-title}. The `kn func` CLI is provided as a plug-in for the Knative `kn` CLI. {FunctionsProductName} uses the link:https://buildpacks.io/[CNCF Buildpack API] to create container images. After a container image is created, you can use the `kn func` CLI to deploy the container image as a Knative service on the cluster. +With {FunctionsProductName}, developers can create and deploy stateless, event-driven functions as a Knative service on {product-title}. The Knative (`kn`) CLI is provided as a plug-in for the Knative CLI. {FunctionsProductName} uses the link:https://buildpacks.io/[CNCF Buildpack API] to create container images. After a container image is created, you can use the `kn func` CLI to deploy the container image as a Knative service on the cluster. :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] @@ -19,7 +19,7 @@ include::snippets/technology-preview.adoc[leveloffset=+2] // add xref links to docs once added * xref:../../serverless/functions/serverless-developing-nodejs-functions.adoc#serverless-developing-nodejs-functions[Node.js] * xref:../../serverless/functions/serverless-developing-python-functions.adoc#serverless-developing-python-functions[Python] -* xref:../../serverless/functions/serverless-developing-go-functions.adoc#serverless-developing-go-functions[Golang] +* xref:../../serverless/functions/serverless-developing-go-functions.adoc#serverless-developing-go-functions[Go] * xref:../../serverless/functions/serverless-developing-quarkus-functions.adoc#serverless-developing-quarkus-functions[Quarkus] * xref:../../serverless/functions/serverless-developing-typescript-functions.adoc#serverless-developing-typescript-functions[TypeScript] diff --git a/serverless/functions/serverless-developing-go-functions.adoc b/serverless/functions/serverless-developing-go-functions.adoc index df99fef835..132f15066c 100644 --- a/serverless/functions/serverless-developing-go-functions.adoc +++ b/serverless/functions/serverless-developing-go-functions.adoc @@ -1,6 +1,6 @@ :_content-type: ASSEMBLY [id="serverless-developing-go-functions"] -= Developing Golang functions += Developing Go functions :context: serverless-developing-go-functions include::_attributes/common-attributes.adoc[] @@ -9,7 +9,7 @@ toc::[] :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] -After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a Golang function project], you can modify the template files provided to add business logic to your function. +After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a Go function project], you can modify the template files provided to add business logic to your function. This includes configuring function invocation and the returned headers and status codes. [id="prerequisites_serverless-developing-go-functions"] == Prerequisites @@ -19,9 +19,9 @@ After you have xref:../../serverless/functions/serverless-functions-getting-star include::modules/serverless-go-template.adoc[leveloffset=+1] [id="serverless-developing-go-functions-about-invoking"] -== About invoking Golang functions +== About invoking Go functions -Golang functions are invoked by using different methods, depending on whether they are triggered by an HTTP request or a CloudEvent. +When using the Knative (`kn`) CLI to create a function project, you can generate a project that responds to CloudEvents, or one that responds to simple HTTP requests. Go functions are invoked by using different methods, depending on whether they are triggered by an HTTP request or a CloudEvent. include::modules/serverless-invoking-go-functions-http.adoc[leveloffset=+2] include::modules/serverless-invoking-go-functions-cloudevent.adoc[leveloffset=+2] diff --git a/serverless/functions/serverless-developing-nodejs-functions.adoc b/serverless/functions/serverless-developing-nodejs-functions.adoc index cfbc1c426c..af4a2f0af3 100644 --- a/serverless/functions/serverless-developing-nodejs-functions.adoc +++ b/serverless/functions/serverless-developing-nodejs-functions.adoc @@ -9,7 +9,7 @@ toc::[] :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] -After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a Node.js function project], you can modify the template files provided to add business logic to your function. +After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a Node.js function project], you can modify the template files provided to add business logic to your function. This includes configuring function invocation and the returned headers and status codes. [id="prerequisites_serverless-developing-nodejs-functions"] == Prerequisites @@ -21,7 +21,7 @@ include::modules/serverless-nodejs-template.adoc[leveloffset=+1] [id="serverless-developing-nodejs-functions-about-invoking"] == About invoking Node.js functions -When using the `kn` CLI to create a function project, you can generate a project that responds to CloudEvents, or one that responds to simple HTTP requests. CloudEvents in Knative are transported over HTTP as a POST request, so both function types listen for and respond to incoming HTTP events. +When using the Knative (`kn`) CLI to create a function project, you can generate a project that responds to CloudEvents, or one that responds to simple HTTP requests. CloudEvents in Knative are transported over HTTP as a POST request, so both function types listen for and respond to incoming HTTP events. Node.js functions can be invoked with a simple HTTP request. When an incoming request is received, functions are invoked with a `context` object as the first parameter. diff --git a/serverless/functions/serverless-developing-python-functions.adoc b/serverless/functions/serverless-developing-python-functions.adoc index 0c70d16a9a..6f93d925aa 100644 --- a/serverless/functions/serverless-developing-python-functions.adoc +++ b/serverless/functions/serverless-developing-python-functions.adoc @@ -9,7 +9,7 @@ toc::[] :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] -After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a Python function project], you can modify the template files provided to add business logic to your function. +After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a Python function project], you can modify the template files provided to add business logic to your function. This includes configuring function invocation and the returned headers and status codes. [id="prerequisites_serverless-developing-python-functions"] == Prerequisites diff --git a/serverless/functions/serverless-developing-quarkus-functions.adoc b/serverless/functions/serverless-developing-quarkus-functions.adoc index a423e0ac27..69c8c4f583 100644 --- a/serverless/functions/serverless-developing-quarkus-functions.adoc +++ b/serverless/functions/serverless-developing-quarkus-functions.adoc @@ -9,7 +9,7 @@ toc::[] :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] -After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a Quarkus function project], you can modify the template files provided to add business logic to your function. +After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a Quarkus function project], you can modify the template files provided to add business logic to your function. This includes configuring function invocation and the returned headers and status codes. [id="prerequisites_serverless-developing-quarkus-functions"] == Prerequisites diff --git a/serverless/functions/serverless-developing-typescript-functions.adoc b/serverless/functions/serverless-developing-typescript-functions.adoc index 0acc7b67ea..ba69c6400f 100644 --- a/serverless/functions/serverless-developing-typescript-functions.adoc +++ b/serverless/functions/serverless-developing-typescript-functions.adoc @@ -9,7 +9,7 @@ toc::[] :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] -After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a TypeScript function project], you can modify the template files provided to add business logic to your function. +After you have xref:../../serverless/functions/serverless-functions-getting-started.adoc#serverless-create-func-kn_serverless-functions-getting-started[created a TypeScript function project], you can modify the template files provided to add business logic to your function. This includes configuring function invocation and the returned headers and status codes. [id="prerequisites_serverless-developing-typescript-functions"] == Prerequisites @@ -21,7 +21,7 @@ include::modules/serverless-typescript-template.adoc[leveloffset=+1] [id="serverless-developing-typescript-functions-about-invoking"] == About invoking TypeScript functions -When using the `kn` CLI to create a function project, you can generate a project that responds to CloudEvents or one that responds to simple HTTP requests. CloudEvents in Knative are transported over HTTP as a POST request, so both function types listen for and respond to incoming HTTP events. +When using the Knative (`kn`) CLI to create a function project, you can generate a project that responds to CloudEvents or one that responds to simple HTTP requests. CloudEvents in Knative are transported over HTTP as a POST request, so both function types listen for and respond to incoming HTTP events. TypeScript functions can be invoked with a simple HTTP request. When an incoming request is received, functions are invoked with a `context` object as the first parameter. diff --git a/serverless/functions/serverless-functions-accessing-secrets-configmaps.adoc b/serverless/functions/serverless-functions-accessing-secrets-configmaps.adoc index 6aa074543c..4b2c65825b 100644 --- a/serverless/functions/serverless-functions-accessing-secrets-configmaps.adoc +++ b/serverless/functions/serverless-functions-accessing-secrets-configmaps.adoc @@ -21,7 +21,7 @@ include::modules/serverless-functions-secrets-configmaps-interactively-specializ [id="serverless-functions-secrets-configmaps-manually_{context}"] == Adding function access to secrets and config maps manually -You can manually add configuration for accessing secrets and config maps to your function. +You can manually add configuration for accessing secrets and config maps to your function. This might be preferable to using the `kn func config` interactive utility and commands, for example when you have an existing configuration snippet. include::modules/serverless-functions-mounting-secret-as-volume.adoc[leveloffset=+2] include::modules/serverless-functions-mounting-configmap-as-volume.adoc[leveloffset=+2] diff --git a/serverless/functions/serverless-functions-annotations.adoc b/serverless/functions/serverless-functions-annotations.adoc index f677c30a0f..4e2f443c15 100644 --- a/serverless/functions/serverless-functions-annotations.adoc +++ b/serverless/functions/serverless-functions-annotations.adoc @@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -You can add Kubernetes annotations to a deployed Serverless function by adding them to the `annotations` section in the `func.yaml` configuration file. +You can add Kubernetes annotations to a deployed Serverless function. Annotations enable you to attach arbitrary metadata to a function, for example, a note about the function's purpose. Annotations are added to the `annotations` section of the `func.yaml` configuration file. There are two limitations of the function annotation feature: diff --git a/serverless/functions/serverless-functions-annotations.html b/serverless/functions/serverless-functions-annotations.html new file mode 100644 index 0000000000..5a445589b0 --- /dev/null +++ b/serverless/functions/serverless-functions-annotations.html @@ -0,0 +1,547 @@ + + + + + + + +Adding annotations to functions + + + + + +
+
+
+ +
+

You can add Kubernetes annotations to a deployed Serverless function. This is done in the annotations section of the func.yaml configuration file.

+
+
+

There are two limitations of the function annotation feature:

+
+
+
    +
  • +

    After a function annotation propagates to the corresponding Knative service on the cluster, it cannot be removed from the service by deleting it from the func.yaml file. You must remove the annotation from the Knative service by modifying the YAML file of the service directly, or by using the {product-title} web console.

    +
    • +
  • +

    You cannot set annotations that are set by Knative, for example, the autoscaling annotations.

    +
    • +
+
+
+
+
+

Adding annotations to a function

+
+
+

You can use the following procedure to add annotations to a function.

+
+
+
Prerequisites
+
    +
  • +

    The OpenShift Serverless Operator and Knative Serving are installed on the cluster.

    +
    • +
  • +

    You have installed the kn CLI.

    +
    • +
  • +

    You have created a function.

    +
    • +
+
+
+
Procedure
+
    +
  1. +

    Open the func.yaml file for your function.

    +
    2. +
  2. +

    For every annotation that you want to add, add the following YAML to the annotations section:

    +
    +
    +
    name: test
+namespace: ""
+runtime: go
+...
+annotations:
+  <annotation_name>: "<annotation_value>" 1
    +
    +
    +
    + + + + + +
    1Substitute <annotation_name>: "<annotation_value>" with your annotation.
    +
    +
    +

    For example, to indicate that a function was authored by Alice, you might include the following annotation:

    +
    +
    +
    +
    name: test
+namespace: ""
+runtime: go
+...
+annotations:
+  author: "alice@example.com"
    +
    +
    +
    3. +
  3. +

    Save the configuration.

    +
    4. +
+
+
+

The next time you deploy your function to the cluster, the annotations are added to the corresponding Knative service.

+
+
+
+
+ + + \ No newline at end of file diff --git a/serverless/functions/serverless-functions-eventing.adoc b/serverless/functions/serverless-functions-eventing.adoc index f93ddf4388..3a0ee5bf53 100644 --- a/serverless/functions/serverless-functions-eventing.adoc +++ b/serverless/functions/serverless-functions-eventing.adoc @@ -9,6 +9,6 @@ toc::[] :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] -Functions are deployed as a Knative service on an {product-title} cluster, and can be connected as a sink to Knative Eventing components. +Functions are deployed as Knative services on an {product-title} cluster. You can connect functions as an event sink to Knative Eventing components so that they can receive incoming events. include::modules/serverless-connect-sink-source-odc.adoc[leveloffset=+1] diff --git a/serverless/functions/serverless-functions-getting-started.adoc b/serverless/functions/serverless-functions-getting-started.adoc index f365b4e6a0..0e52694f8e 100644 --- a/serverless/functions/serverless-functions-getting-started.adoc +++ b/serverless/functions/serverless-functions-getting-started.adoc @@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -This guide explains how you can get started with creating, building, and deploying a function on an {ServerlessProductName} installation. When building and deploying functions, the resulting container image is stored in an image registry. +Function lifecycle management includes creating, building, and deploying a function. Optionally, you can also test a deployed function by invoking it. You can do all of these operations on {ServerlessProductName} using the `kn func` tool. :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] diff --git a/serverless/functions/serverless-functions-reference-guide.adoc b/serverless/functions/serverless-functions-reference-guide.adoc index 21528a5c87..cb8875e94e 100644 --- a/serverless/functions/serverless-functions-reference-guide.adoc +++ b/serverless/functions/serverless-functions-reference-guide.adoc @@ -9,17 +9,17 @@ toc::[] :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] -{FunctionsProductName} provides templates that can be used to create basic functions for the following runtimes: +{FunctionsProductName} provides templates that can be used to create basic functions. A template initiates the function project boilerplate and prepares it for use with the `kn func` tool. Each function template is tailored for a specific runtime and follows its conventions. With a template, you can initiate your function project automatically. + +Templates for the following runtimes are available: // add xref links to docs once added * xref:../../serverless/functions/serverless-developing-nodejs-functions.adoc#serverless-developing-nodejs-functions[Node.js] * xref:../../serverless/functions/serverless-developing-python-functions.adoc#serverless-developing-python-functions[Python] -* xref:../../serverless/functions/serverless-developing-go-functions.adoc#serverless-developing-go-functions[Golang] +* xref:../../serverless/functions/serverless-developing-go-functions.adoc#serverless-developing-go-functions[Go] * xref:../../serverless/functions/serverless-developing-quarkus-functions.adoc#serverless-developing-quarkus-functions[Quarkus] * xref:../../serverless/functions/serverless-developing-typescript-functions.adoc#serverless-developing-typescript-functions[TypeScript] //* SpringBoot - TBC -This guide provides reference information that you can use to develop functions. - include::modules/serverless-nodejs-context-object-reference.adoc[leveloffset=+1] include::modules/serverless-typescript-context-object-reference.adoc[leveloffset=+1] diff --git a/serverless/functions/serverless-functions-setup.adoc b/serverless/functions/serverless-functions-setup.adoc index 6ff4b1d17f..aab9a3363c 100644 --- a/serverless/functions/serverless-functions-setup.adoc +++ b/serverless/functions/serverless-functions-setup.adoc @@ -9,7 +9,7 @@ toc::[] :FeatureName: {FunctionsProductName} include::snippets/technology-preview.adoc[leveloffset=+2] -Before you can develop functions on {ServerlessProductName}, you must complete the set up steps. +To improve the process of deployment of your application code, you can use {ServerlessProductName} to deploy stateless, event-driven functions as a Knative service on {product-title}. If you want to develop functions, you must complete the set up steps. [id="prerequisites_serverless-functions-setup"] == Prerequisites @@ -32,7 +32,7 @@ ifdef::openshift-dedicated,openshift-rosa[] * The `oc` CLI is installed on your cluster. endif::[] -* The xref:../../serverless/cli_tools/installing-kn.adoc#installing-kn[Knative (`kn`) CLI] is installed on your cluster. Installing the `kn` CLI enables the use of `kn func` commands which you can use to create and manage functions. +* The xref:../../serverless/cli_tools/installing-kn.adoc#installing-kn[Knative (`kn`) CLI] is installed on your cluster. Installing the Knative CLI enables the use of `kn func` commands which you can use to create and manage functions. * You have installed Docker Container Engine or podman version 3.3 or higher, and have access to an available image registry. diff --git a/serverless/functions/serverless-functions-yaml.adoc b/serverless/functions/serverless-functions-yaml.adoc index e7e907b362..ccb0e6be65 100644 --- a/serverless/functions/serverless-functions-yaml.adoc +++ b/serverless/functions/serverless-functions-yaml.adoc @@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -The `func.yaml` file contains the configuration for your function project. These values are used when you execute a `kn func` command. For example, when you run the `kn func build` command, the value in the `builder` field is used. In some cases, you can override these values with command line flags or environment variables. +The `func.yaml` file contains the configuration for your function project. Values specified in `func.yaml` are used when you execute a `kn func` command. For example, when you run the `kn func build` command, the value in the `builder` field is used. In some cases, you can override these values with command line flags or environment variables. include::modules/serverless-functions-func-yaml-fields.adoc[leveloffset=+1] include::modules/serverless-functions-func-yaml-environment-variables.adoc[leveloffset=+1]