Merge pull request #496 from cloud-docs/next-publish-push

Next publish push

Author: foverby

batch-tutorial.md

@@ -2,7 +2,7 @@
 
 copyright:
   years: 2020, 2024
-lastupdated: "2024-01-25"
+lastupdated: "2024-02-15"
 
 keywords: job tutorial, jobs, images for code engine jobs, tutorial for code engine, job log
 
@@ -56,8 +56,8 @@ After you create your job and specify your workload configuration information, y
 Note that when you run your job, the latest version of your referenced container image is downloaded and deployed, unless you specified a tag for the image. If a tag is specified for the image, then the tagged image is used for the job. 
 
 1. Navigate to your job page. 
-    * From the [{{site.data.keyword.codeengineshort}} Projects page](https://cloud.ibm.com/codeengine/projects){: external}, click the name of your project. Click **Jobs** to open a listing of your jobs.   
-    * From the Jobs page, click the name of the job that you want to run. 
+    * From the [{{site.data.keyword.codeengineshort}} Projects page](https://cloud.ibm.com/codeengine/projects){: external}, click the name of your project. Click **Jobs** to work with your jobs and job runs. 
+    * From the Jobs page, click the **Jobs** tab, and click the name of the job that you want to run. 
 
 2. From your job page, click **Submit job** to submit a job that is based on the current configuration. 
 3. From the Submit job pane, accept all the default values, and click **Submit job** again to run your job.
@@ -74,7 +74,10 @@ From the Submit job pane, you can review and optionally change default configura
 Find details about your job.
 {: shortdesc}
 
-After you submit your job, the job results are available in the console from the Job details page. In the console, you can also view job details by clicking the name of your job run from the **Job runs** section of your job. Job details include status of instances, configuration details, and environment variables of your job. 
+After you submit your job, the results of the specific job run are available in the console from the Job run details page. From the console, you can also view details of your job and specific job runs from the Jobs page. 
+* To view job details, click the **Jobs** tab, and click the name of the job you want to work with. 
+* To view details for a specific job run, click the **Job runs** tab, and click the name of the job run that you want to work with. 
+
 
 If any of the instances of your job failed to run, you can take the following actions.
 
@@ -95,10 +98,10 @@ You can manage your job by fine tuning your job configuration, which includes up
 When the job is in a ready state, you can update the job. Let's update the job that you created previously to change the container image from `icr.io/codeengine/firstjob` to `icr.io/codeengine/testjob` and then update an environment variable. When a request is sent to this `icr.io/codeengine/testjob` sample job, the job reads the environment variable `TARGET` and prints `"Hello ${TARGET}!"`. If this environment variable is empty, `"Hello World!"` is returned. For more information about the code that is used for this example, see [`testjob`](https://github.com/IBM/CodeEngine/tree/main/testjob){: external}.
 
 1. Navigate to your job page. 
-    * From the [{{site.data.keyword.codeengineshort}} Projects page](https://cloud.ibm.com/codeengine/projects){: external}, click the name of your project. Click **Jobs** to open a listing of your jobs.   
-    * From the Jobs page, click the name of the job that you want to update. 
+    * From the [{{site.data.keyword.codeengineshort}} Projects page](https://cloud.ibm.com/codeengine/projects){: external}, click the name of your project. Click **Jobs** to work with your jobs and job runs.
+    * From the Jobs page, click the **Jobs** tab, and click the name of the job that you want to update. 
 
-2. To update the image reference of your job, provide the name of your image or configure an image. Update the name of the image from `icr.io/codeengine/firstjob` to `icr.io/codeengine/testjob`. Click **Save**. 
+2. From the **Configuration** tab, update the image reference of your job. Provide the name of your image or configure an image. Update the name of the image from `icr.io/codeengine/firstjob` to `icr.io/codeengine/testjob`. Click **Deploy**. 
 3. Click **Submit job**.
 4. From the Submit job pane, review and optionally change default configuration values such as instances, CPU, memory, number of job retries, and job timeout. You can specify either **Array size** or **Array indices** for the parallel job instances to run. For **Array size**, provide the number of instances to run in parallel for this job. For **Array indices**, provide a comma-separated list for your custom set of indices. For example, to run this job with a custom set of `5` indices, specify `3,12-14,25`. Click **Submit job** again to run your job. The system displays the status of the instances of your job on the Job details page. 
 5. By [viewing job logs from the console](/docs/codeengine?topic=codeengine-view-logs#view-joblogs-ui) for this job, the output of the job is `Hello World!`.

billing.md

@@ -2,7 +2,7 @@
 
 copyright:
   years: 2024
-lastupdated: "2024-02-14"
+lastupdated: "2024-02-15"
 
 keywords: billing, pricing, costs for code engine, billing for code engine, job pricing, app pricing, build pricing
 
@@ -24,6 +24,7 @@ You are billed for the following entities,
 
 - [Applications](#app-pricing)
 - [Job runs](#job-pricing)
+- [Functions](#functions-pricing)
 - [Build runs](#build-pricing)
 
 Entities such as [projects](/docs/codeengine?topic=codeengine-manage-project) do not incur charges, but instead serve as a folder for your entities. Entities such as secrets, bindings, or subscriptions do not incur charges, but do contribute to the overall limits of your project. For more information, see [Limits and quotas for {{site.data.keyword.codeengineshort}}](/docs/codeengine?topic=codeengine-limits).
@@ -59,6 +60,18 @@ For valid CPU and memory combinations, see [Supported memory and CPU combination
 
 Note that the time that it takes to pull your image or to build it from source code is included in the billable time.
 
+## Function pricing
+{: #functions-pricing}
+
+When you deploy a function, charges apply for HTTP requests, and for the CPU and memory resources that are consumed by running instances of the function. Incoming HTTP calls are billed by the number of HTTP calls that are received by your function. For example,
+* If your function serves 100 calls, you are then billed for 100 HTTP calls. Internal HTTP traffic within a {{site.data.keyword.codeengineshort}} project between your workloads is excluded from the billable HTTP call total. 
+* If you create a {{site.data.keyword.codeengineshort}} function with 2 GB memory and 0.5 virtual CPU, after 600 invocations (assuming each requires 6 seconds to complete the result), you are charged for 0.5 vCPU hour and 2 GB hours. 
+  
+For valid CPU and memory combinations, see [Supported memory and CPU combinations](/docs/codeengine?topic=codeengine-mem-cpu-combo).
+
+The time that it takes to pull your code bundle or to build it from source code is included in the billable time. 
+{: note}
+
 
 
 ## Build pricing

envvar-autoinject.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2020, 2023
-lastupdated: "2023-11-30"
+  years: 2020, 2024
+lastupdated: "2024-02-16"
 
 keywords: applications in code engine, apps in code engine, http requests in code engine, deploy apps in code engine, app workloads in code engine, deploying workloads in code engine, application, app, memory, cpu, environment variables
 
@@ -68,4 +68,26 @@ Note that each job run instance gets its own index from the array of indices tha
 
 While the job itself doesn't have a URL associated with it, the `CE_DOMAIN` and `CE_SUBDOMAIN` values might be useful if you need to reference an application that is running in the same project. The full external URL of this application is `appName.CE_SUBDOMAIN.CE_DOMAIN`. To reference the private URL of an application, use `appName.CE_SUBDOMAIN`.
 
+## Automatically injected environment variables for functions
+{: #inside-env-vars-fun}
+
+When you deploy an function, {{site.data.keyword.codeengineshort}} automatically injects certain environment variables into the function.  The following table lists automatically injected environment variables into each instance of your deployed function. 
+
+The environment variables, `CE_FUNCTION`, `CE_DOMAIN`, and `CE_SUBDOMAIN` are used to construct the URL of a function, `https://CE_FUNCTION.CE_SUBDOMAIN.CE_DOMAIN`. For example, if `CE_FUNCTION=myfunc`, `CE_SUBDOMAIN=01234567-abcd` and `CE_DOMAIN=us-south.codeengine.dev.appdomain.cloud`, your function external URL is `https://myfunc.01234567-abcd.us-south.codeengine.dev.appdomain.cloud`. The private URL of your application is `CE_FUNCTION.CE_SUBDOMAIN.private.CE_DOMAIN`, or `myfunc.01234567-abcd.private.us-south.codeengine.appdomain.cloud`. 
+
+| Environment variable | Description | Example |
+|--------------------|-------------------------------------------------------|--------------|
+| `CE_ALLOW_CONCURRENT`| This internal boolean setting is used by the {{site.data.keyword.codeengineshort}} function controller to indicate if the runtime supports concurrent invocations of the same function instance, and can be ignored. | `CE_ALLOW_CONCURRENT=true` |
+| `CE_DOMAIN`          | The domain name portion of the URL of the function (and project).  | `CE_DOMAIN=us-south.codeengine.dev.appdomain.cloud` |
+| `CE_EXECUTION_ENV`   | The managed runtime type and its release version.                     | `CE_EXECUTION_ENV=ibm/action-python-v3.11` This example specifies to use Python v3.11.  |
+| `CE_FUNCTION`        | The name of the function.                                             | `CE_APP=myfunc` |
+| `CE_SUBDOMAIN`       | The subdomain portion of the URL associated with the function (and project). If you are familiar with Kubernetes, `CE_SUBDOMAIN` maps to the Kubernetes namespace associated with your project. | `CE_SUBDOMAIN=01234567-abcd` |
+| `HOME`               | The home directory of the runtime container for the function.         | `HOME=/root` |
+| `LC_CTYPE`           | The locale that is used by the `ctype` and `multibyte` operating system API. Available only with Python runtimes.     | `LC_CTYPE=C.UTF-8` |
+| `PATH`               | The current setting of the PATH variable, which lists the directories in which the system looks for executables. | `PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin` |
+| `PYTHONIOENCODING`   | The standard encoding that is used by standard input, standard output, and standard error streams. This variable only applies to a Python runtime. | `PYTHONIOENCODING=UTF-8` |
+| `PWD`                | The current working directory.                                        | `PWD=/` |
+{: caption="Automatically injected environment variables when deploying {{site.data.keyword.codeengineshort}} functions"}
+
+
 

faq.md

@@ -2,7 +2,7 @@
 
 copyright:
   years: 2020, 2024
-lastupdated: "2024-01-11"
+lastupdated: "2024-02-15"
 
 keywords: faq for code engine, project faq for code engine, feedback for code engine, code samples for code engine, terms of service for code engine, faq, feedback, terms, code samples, project, code engine, limits
 
@@ -78,13 +78,6 @@ The result of a Docker build that you run on your local system is the same conta
 3. You can build your container image by using the [Buildpacks build strategy](/docs/codeengine?topic=codeengine-plan-build#build-strategy) instead of Dockerfile, which detects your sources for various languages and automatically builds a container out of it.
 4. If you have an image that was built with a non-Intel based processor, {{site.data.keyword.codeengineshort}} can rebuild it for you.
 
-## Why do images that are built by using a {{site.data.keyword.codeengineshort}} buildpacks build show up in my container registry as being more than 15,000 days old?
-{: #buildpacksbld-image-size}
-{: faq}
-{: support}
-
-Buildpacks create [reproducible builds](https://buildpacks.io/docs/reference/reproducibility/){: external} of container images. When the same sources are built with the same version of the build tool, then the produced image has the same identifier. The identifier of an image is based not only on the files that are inside the image, but also based on dates in the metadata of the image. Part of this metadata is the creation timestamp. The [Buildpacks community](https://buildpacks.io/community){: external} set all these dates in the image metadata to a fixed timestamp in 1980 to achieve reproducibility.
-
 ## Why do images that are built with non-Intel processors not work with {{site.data.keyword.codeengineshort}}?  
 {: #buildimage-nonintel}
 {: faq}

fun-work.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2023, 2023
-lastupdated: "2023-12-11"
+  years: 2023, 2024
+lastupdated: "2024-02-15"
 
 keywords: code engine, function, create function, code engine function, create code engine function
 
@@ -193,7 +193,7 @@ To run your function in {{site.data.keyword.codeengineshort}}, your code must im
 - Does not support the `multipart/form-data` request header.
 
 
-## Options for visibility for a {{site.data.keyword.codeengineshort}} functions
+## Options for visibility for a {{site.data.keyword.codeengineshort}} function
 {: #optionsvisibilityfun}
 
 With {{site.data.keyword.codeengineshort}}, you can determine the right level of visibility for your function by defining the endpoints, or system domain mappings that are available for receiving requests.  
@@ -205,13 +205,27 @@ You can deploy your function with the following visibility levels:
 
 | Setting | Description |
 | --------- | ------------------- |
-| [internal (project)](#fun-endpoint-projectonly) | A function with this setting can receive requests from components in the same {{site.data.keyword.codeengineshort}} project. Setting an internal (project) endpoint means that your function is not accessible from the public internet and network access is only possible from other {{site.data.keyword.codeengineshort}} components that are running within the same {{site.data.keyword.codeengineshort}} project. This endpoint is always enabled. |
+| [internal (project)](#fun-endpoint-projectonly) | A function with this setting can receive requests from components in the same {{site.data.keyword.codeengineshort}} project. Setting an internal (project) endpoint means that your function is not accessible from the public internet and network access is only possible from other {{site.data.keyword.codeengineshort}} components that are running within the same {{site.data.keyword.codeengineshort}} project. This endpoint is always enabled. **IMPORTANT:** A function cannot invoke another function, job, or app using the internal routes.|
 | [public](#fun-endpoint-public) | A function with this setting is exposed to the internet and your {{site.data.keyword.codeengineshort}} project. Setting a public endpoint means that your function can receive requests from the public internet or from components within your {{site.data.keyword.codeengineshort}} project. This setting is the default. |
 | [private](#fun-endpoint-private) | A function with this setting is exposed to the {{site.data.keyword.cloud_notm}} private network and your {{site.data.keyword.codeengineshort}} project. Setting a private endpoint means that your function is not accessible from the public internet and network access is only possible from other {{site.data.keyword.cloud_notm}} services by using Virtual Private Endpoints (VPE) or {{site.data.keyword.codeengineshort}} components that are running in the same project.|
 {: caption="Table 1. Visibility for functions" caption-side="bottom"}
 
 You can set the endpoint settings for visibility of a function from the console or with the CLI when you create and deploy, or update your function. 
 
+### Deploying your function with an internal endpoint
+{: #fun-endpoint-projectonly}
+
+You can set the endpoint visibility for your function to deploy with an internal (project) endpoint. When you set an internal (project) endpoint, your function is not accessible from the public internet and network access is possible only from other {{site.data.keyword.codeengineshort}} components that are running within the same {{site.data.keyword.codeengineshort}} project. This endpoint is always enabled. Functions are still accessible through shared components and therefore need to be secured.
+
+For example, if your solution consists of several functions within a project, you might set up your solution so that only one of those functions is visible from the internet so that it handles incoming traffic. This public-facing function can delegate work to other functions in your solution so that they do not need to be visible from the internet.
+
+With the CLI, set the endpoint visibility for your function so that it is deployed with a project endpoint by using the `--visibility=project` option on the [**`function create`**](/docs/codeengine?topic=codeengine-cli#cli-function-create) or [**`function update`**](/docs/codeengine?topic=codeengine-cli#cli-function-update) command. You can obtain the available URLs for your function that reflect your endpoint definition by using the [**`function get`**](/docs/codeengine?topic=codeengine-cli#cli-function-get) command.
+
+From the console, set the visibility of endpoints for your function by using the **Endpoints** setting when you create your function. After your function is deployed, you can view and modify these system domain mapping settings on the **Domain mappings** tab on your Functions page.
+
+A function with this setting can receive requests from components in the same {{site.data.keyword.codeengineshort}} project. However, a function cannot invoke another function, job, or app using the internal routes.
+{: important}
+
 ### Deploying your function with a public endpoint
 {: #fun-endpoint-public}
 
@@ -232,16 +246,6 @@ From the console, set the visibility of endpoints for your function by using the
 
 For more information about connecting over private networks, see [Using Virtual Private Endpoints with {{site.data.keyword.codeengineshort}}](/docs/codeengine?topic=codeengine-vpe).
 
-### Deploying your function with a project endpoint
-{: #fun-endpoint-projectonly}
-
-You can set the endpoint visibility for your function to deploy with an internal (project) endpoint. When you set a project-only endpoint, your function is not accessible from the public internet and network access is possible only from other {{site.data.keyword.codeengineshort}} components that are running within the same {{site.data.keyword.codeengineshort}} project. This endpoint is always enabled. Functions are still accessible through shared components and therefore need to be secured.
-
-For example, if your solution consists of several functions within a project, you might set up your solution so that only one of those functions is visible from the internet so that it handles incoming traffic. This public-facing function can delegate work to other functions in your solution so that they do not need to be visible from the internet.
-
-With the CLI, set the endpoint visibility for your function so that it is deployed with a project endpoint by using the `--visibility=project` option on the [**`function create`**](/docs/codeengine?topic=codeengine-cli#cli-function-create) or [**`function update`**](/docs/codeengine?topic=codeengine-cli#cli-function-update) command. You can obtain the available URLs for your function that reflect your endpoint definition by using the [**`function get`**](/docs/codeengine?topic=codeengine-cli#cli-function-get) command.
-
-From the console, set the visibility of endpoints for your function by using the **Endpoints** setting when you create your function. After your function is deployed, you can view and modify these system domain mapping settings on the **Domain mappings** tab on your Functions page.
 
 
 ## Options for creating functions