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

Next publish push

Author: foverby

add-registry.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2020, 2023
-lastupdated: "2023-12-12"
+  years: 2020, 2024
+lastupdated: "2024-01-11"
 
 keywords: registries, container registry, image registry, apikey, API key, access token, images, registry access, registry secret, service id,registry secret, registry access secret
 
@@ -49,10 +49,10 @@ Public registries, such as public Docker Hub, can be used to get started with Do
 
  To access images in a registry, {{site.data.keyword.codeengineshort}} uses one of the following types of registry secrets.
 
-* {{site.data.keyword.codeengineshort}} managed secret - If your registry uses an {{site.data.keyword.registrylong_notm}} namespace that is in your account, then you can let {{site.data.keyword.codeengineshort}} create and manage the registry secret for you. In the console, this automatically created registry access secret is called a `{{site.data.keyword.codeengineshort}} managed secret`. In the CLI, the name of an automatically created registry secret is of the format, `ce-auto-icr-private-<region>`. 
-* User managed secret - This is a secret that you create and manage. You can [access images from your account with an API key](/docs/codeengine?topic=codeengine-add-registry#images-your-account-api-key) or use an access token for the container registry of your choice; for example, Docker Hub. For this case, the registry access secret that is listed in the console is the name of your registry secret. 
+* {{site.data.keyword.codeengineshort}} managed secret - If your registry uses an {{site.data.keyword.registrylong_notm}} namespace that is in your account, then you can let {{site.data.keyword.codeengineshort}} create and manage the registry secret for you. In the console, this automatically created registry secret is called a `{{site.data.keyword.codeengineshort}} managed secret`. In the CLI, the name of an automatically created registry secret is of the format, `ce-auto-icr-private-<region>`. 
+* User managed secret - This is a secret that you create and manage. You can [access images from your account with an API key](/docs/codeengine?topic=codeengine-add-registry#images-your-account-api-key) or use an access token for the container registry of your choice; for example, Docker Hub. For this case, the registry secret that is listed in the console is the name of your registry secret. 
 
-If your registry is public and does not require credentials; for example, {{site.data.keyword.codeengineshort}} sample images in `icr.io/codeengine` or Docker Hub public, then you do not need a registry secret. For this case, the registry access secret that is listed in the console is `None`. 
+If your registry is public and does not require credentials; for example, {{site.data.keyword.codeengineshort}} sample images in `icr.io/codeengine` or Docker Hub public, then you do not need a registry secret. For this case, the registry secret that is listed in the console is `None`. 
 
 
 ## Setting up authorities for image registries
@@ -70,7 +70,7 @@ To determine the authorities that you need, consider the following cases:
 * If you want to access images from a shared account, other {{site.data.keyword.cloud_notm}} accounts, or a private Docker account, you must be assigned the proper access authorities.
 
 * When you deploy apps or run jobs and your registry uses an {{site.data.keyword.registrylong_notm}} namespace that is in your account, then you can let {{site.data.keyword.codeengineshort}} automatically create and manage the registry secret for you, as long as your account has the required permissions as described in the following table.
-    - In the console, this registry access secret is called a `{{site.data.keyword.codeengineshort}} managed secret`. This option is available when you use the **Configure image** or **Specify build details** workflows for building an image with {{site.data.keyword.codeengineshort}}.
+    - In the console, this registry secret is called a `{{site.data.keyword.codeengineshort}} managed secret`. This option is available when you use the **Configure image** or **Specify build details** workflows for building an image with {{site.data.keyword.codeengineshort}}.
     - In the CLI, this registry secret is of the format, `ce-auto-icr-private-<region>`. This registry secret is automatically created when you specify the `--build-source` option but you do not provide the `--registry-secret` option with the **`app create`**, **`app update`**, **`job create`**, or **`job update`** commands. 
 
 

api-changelog.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2022, 2023
-lastupdated: "2023-11-03"
+  years: 2022, 2024
+lastupdated: "2024-01-12"
 
 keywords: api change log for code engine, api version for code engine, change log for api in code engine, api history for code engine, change log, api version history
 
@@ -36,6 +36,13 @@ The following table shows the service behavior changes for each version date. Sw
 |`2021-Mar-31`| Version 1.0.0  |
 {: caption="Table 1. Changes in the IBM Cloud Code Engine API" caption-side="bottom"} 
 
+## 04 January 2024
+{: #04-jan-2024}
+
+Added support for the `scale_array_size_variable_override` property for job runs.
+:   - See [Create a job run API](https://cloud.ibm.com/apidocs/codeengine/v2#create-job-run){: external}.
+
+
 ## 03 November 2023
 {: #03-nov-2023}
 

app-scale.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2020, 2023
-lastupdated: "2023-08-31"
+  years: 2020, 2024
+lastupdated: "2024-01-11"
 
 keywords: application scaling in code engine, scaling http requests in code engine, concurrency in code engine applications, latency in code engine applications, throughput in code engine applications, scaling, latency, concurrency, app
 
@@ -41,9 +41,9 @@ You can configure scaling boundaries by setting a range of values for the minimu
 {: shortdesc} 
 
 
-- Minimum number of instances -  The minimum number of instances of the app that are always running, even if no requests are processed. When set to `0` (default) {{site.data.keyword.codeengineshort}} removes all instances when no traffic is reaching the application. To always keep a running instance of your application, set this value greater than `0`. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the minimum number of instances value in the Autoscaling section of the **Runtime** tab. With the CLI, specify the `--min-scale` option on the **`app create`** and **`app update`** commands. 
+- Minimum number of instances -  The minimum number of instances of the app that are always running, even if no requests are processed. When set to `0` (default) {{site.data.keyword.codeengineshort}} removes all instances when no traffic is reaching the application. To always keep a running instance of your application, set this value greater than `0`. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the minimum number of instances value in the Autoscaling section of the **Resources & scaling** tab. With the CLI, specify the `--min-scale` option on the **`app create`** and **`app update`** commands. 
 
-- Maximum number of instances -  The maximum number of instances that can be running for the app. Autoscaling occurs up to this limit. If you set this value to `0`, the application scales as needed, and the app scaling is limited only by the instances per the resource quota for the project of your app. See [Limits and quotas for {{site.data.keyword.codeengineshort}}](/docs/codeengine?topic=codeengine-limits). When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the maximum number of instances value in the Autoscaling section of the **Runtime** tab. With the CLI, specify the `--max-scale` option on the **`app create`** and **`app update`** commands. The default value for this option is `10`.
+- Maximum number of instances -  The maximum number of instances that can be running for the app. Autoscaling occurs up to this limit. If you set this value to `0`, the application scales as needed, and the app scaling is limited only by the instances per the resource quota for the project of your app. See [Limits and quotas for {{site.data.keyword.codeengineshort}}](/docs/codeengine?topic=codeengine-limits). When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the maximum number of instances value in the Autoscaling section of the **Resources & scaling** tab. With the CLI, specify the `--max-scale` option on the **`app create`** and **`app update`** commands. The default value for this option is `10`.
 
 When you connect your applications to event producers, remember to account for the frequency and volume of the events from those producers when you set your scale boundaries. For example, if you expect to receive many events at the same time and the processing of each event can take several minutes, then you might need a higher maximum scale value than if each event can be quickly processed. If you set the value too low, you might experience delays in receiving events, or even dropped events due to timeouts while you wait for processing resources to be free.
 
@@ -52,13 +52,13 @@ When you connect your applications to event producers, remember to account for t
 
 Use the following configuration settings to control application scaling.
 
-- Concurrency -  This value indicates how many requests each instance of your app can process at one time. For example, a currency value of 100 means that your code can handle 100 concurrent requests at the same time. This value is a "hard limit", meaning that {{site.data.keyword.codeengineshort}} does not allow more than the number of requests (as specified with the concurrency setting) to reach any one instance of your application. Therefore, if your code is single threaded and can process only one request at a time, then consider setting concurrency to `1`. When the specified number of requests are sent to all running instances of your application, {{site.data.keyword.codeengineshort}} then increases the number of instances in preparation for more requests. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the max concurrency value in the Autoscaling section of the **Runtime** tab. With the CLI, specify the `--concurrency` option on the **`app create`** and **`app update`** commands.
+- Concurrency -  This value indicates how many requests each instance of your app can process at one time. For example, a currency value of 100 means that your code can handle 100 concurrent requests at the same time. This value is a "hard limit", meaning that {{site.data.keyword.codeengineshort}} does not allow more than the number of requests (as specified with the concurrency setting) to reach any one instance of your application. Therefore, if your code is single threaded and can process only one request at a time, then consider setting concurrency to `1`. When the specified number of requests are sent to all running instances of your application, {{site.data.keyword.codeengineshort}} then increases the number of instances in preparation for more requests. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the max concurrency value in the Autoscaling section of the **Resources & scaling** tab. With the CLI, specify the `--concurrency` option on the **`app create`** and **`app update`** commands.
 
-- Target concurrency -  This value acts as a "soft limit" or number of requests per instance that you want in a loaded system. For example, if you specify `concurrency` as `100`, and you specify `target concurrency` as `70`, then {{site.data.keyword.codeengineshort}} tries to limit the number of requests per instance to 70. Specifying this option doesn't ensure that requests per instance won't go higher than 70 because it most likely will during an increase in traffic. However, the buffer between 70 and 100 enables the system to create new instances to bring the load per instance back down to 70 (or lower) per instance. If `target concurrency` is not specified, the default is the value of `concurrency`. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the target concurrency value in the Autoscaling section of the **Runtime** tab. With the CLI, specify the `--concurrency-target` option on the **`app create`** and **`app update`** commands. 
+- Target concurrency -  This value acts as a "soft limit" or number of requests per instance that you want in a loaded system. For example, if you specify `concurrency` as `100`, and you specify `target concurrency` as `70`, then {{site.data.keyword.codeengineshort}} tries to limit the number of requests per instance to 70. Specifying this option doesn't ensure that requests per instance won't go higher than 70 because it most likely will during an increase in traffic. However, the buffer between 70 and 100 enables the system to create new instances to bring the load per instance back down to 70 (or lower) per instance. If `target concurrency` is not specified, the default is the value of `concurrency`. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the target concurrency value in the Autoscaling section of the **Resources & scaling** tab. With the CLI, specify the `--concurrency-target` option on the **`app create`** and **`app update`** commands. 
 
-- Request timeout -  The amount of time, in seconds, that the application must respond to requests, or else they fail. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the request timeout value in the Autoscaling section of the **Runtime** tab. With the CLI, specify the `--request-timeout` option on the **`app create`** and **`app update`** commands. 
+- Request timeout -  The amount of time, in seconds, that the application must respond to requests, or else they fail. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the request timeout value in the Autoscaling section of the **Resources & scaling** tab. With the CLI, specify the `--request-timeout` option on the **`app create`** and **`app update`** commands. 
 
-- Scale-down delay -  The amount of time, in seconds, that must pass at reduced concurrency before the application scales down. If you know the pattern of incoming requests to your application, you might choose to specify a value greater than the default of `0` to delay the scaling down of your application. If you use a high value for this option the average number of concurrently running application instances might increase, which incurs additional cost. Even with a scale-down delay setting of `0`, the system waits for a short amount of time before the application scales down the number of instances to ensure that a drop in request concurrency is stable enough to warrant a scale down. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the scale-down delay value in the Autoscaling section of the **Runtime** tab. With the CLI, specify the `--scale-down-delay` option on the **`app create`** and **`app update`** commands. 
+- Scale-down delay -  The amount of time, in seconds, that must pass at reduced concurrency before the application scales down. If you know the pattern of incoming requests to your application, you might choose to specify a value greater than the default of `0` to delay the scaling down of your application. If you use a high value for this option the average number of concurrently running application instances might increase, which incurs additional cost. Even with a scale-down delay setting of `0`, the system waits for a short amount of time before the application scales down the number of instances to ensure that a drop in request concurrency is stable enough to warrant a scale down. When you create or update an application with {{site.data.keyword.codeengineshort}} from the console, set the scale-down delay value in the Autoscaling section of the **Resources & scaling** tab. With the CLI, specify the `--scale-down-delay` option on the **`app create`** and **`app update`** commands. 
 
 For example, if the maximum number of instances value is set to `10` and the concurrency is set to `100`, then an application can process 1000 concurrent requests before potential queuing of requests might occur. If you expect more than 1000 requests concurrently, then you might consider increasing the maximum number of instances value for your app. 
 

appdeploy-cr.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2020, 2023
-lastupdated: "2023-09-27"
+  years: 2020, 2024
+lastupdated: "2024-01-09"
 
 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, registry secret, registry access, registry access secret
 
@@ -37,13 +37,13 @@ Deploy an application that uses an image in {{site.data.keyword.registryshort}}
 {{site.data.keyword.codeengineshort}} can automatically pull images from a {{site.data.keyword.registryshort}} namespace in your account. To pull images from a different {{site.data.keyword.registryshort}} account or from a private Docker Hub account, see [Deploying application workloads from images in a private registry](/docs/codeengine?topic=codeengine-deploy-app-private). 
 
 1. Open the [{{site.data.keyword.codeengineshort}}](https://cloud.ibm.com/codeengine/overview){: external} console.
-2. Select **Start creating** from **Run a container image**.
+2. Select **Let's go**.
 3. Select **Application**.
 4. Enter a name for the application; for example, `helloapp`. Use a name for your application that is unique within the project. 
 5. Select a project from the list of available projects. You can also [create a new one](/docs/codeengine?topic=codeengine-manage-project#create-a-project). You must have a selected project to deploy an app. 
 6. Select **Container image** and click **Configure image**. 
-7. Select a container registry location, such as `IBM Registry, Dallas`.
-8. Select `{{site.data.keyword.codeengineshort}} managed secret` for **Registry access secret**. Because this example uses an image in a {{site.data.keyword.registryshort}} namespace in your account, {{site.data.keyword.codeengineshort}} can automatically create and manage the registry access secret for you. 
+7. Select a container registry location, such as `IBM Registry Dallas`.
+8. Select `{{site.data.keyword.codeengineshort}} managed secret` for **Registry secret**. Because this example uses an image in a {{site.data.keyword.registryshort}} namespace in your account, {{site.data.keyword.codeengineshort}} can automatically create and manage the registry secret for you. 
 9. Select an existing namespace and name of the image in the registry for the {{site.data.keyword.codeengineshort}} app to reference. For example, select `mynamespace` and select the image `hello_repo` in that namespace.
 10. Select a value for **Tag**; for example, `latest`.
 11. Click **Done**.