vania-janet/multiturn-rag-retrieval-data huggingface dataset:
New UK English and Arabic models
: The service supports more languages with its transcription models: en-UK_BroadbandModel and en-UK_NarrowbandModel for UK English, and ar-AR_BroadbandModel for Modern Standard Arabic. For more information, see [Previous-generation languages and models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-models).

New session_closed field for session-based methods
: In the JSON responses that it returns for errors with session-based methods, the service now also includes a new session_closed field. The field is set to true if the session is closed as a result of the error. For more information about possible return codes for any method, see the [API & SDK reference](https://cloud.ibm.com/apidocs/speech-to-text).

HTTP platform timeout no longer applies
: HTTP recognition requests are no longer subject to a 10-minute platform timeout. The service now keeps the connection alive by sending a space character in the response JSON object every 20 seconds as long as recognition is ongoing. For more information, see [Timeouts](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-inputtimeouts).

Rate limiting with curl command no longer needed
: When you use the curl command to transcribe audio with the service, you no longer need to use the --limit-rate option to transfer data at a rate no faster than 40,000 bytes per second.

Changes to HTTP error codes
: The service no longer returns HTTP status code 490 for the session-based HTTP methods GET /v1/sessions/{session_id}/observe_result and POST /v1/sessions/{session_id}/recognize. The service now responds with HTTP status code 400 instead.





 21 September 2015 

New mobile SDKs available
: Two new beta mobile SDKs are available for the speech services. The SDKs enable mobile applications to interact with both the Speech to Text and Text to Speech services.
Depending on the programming language, your code might use a code library or module to access the Cloud Foundry runtime environment, locally injected configuration ("dotenv"), and more. Those sections must be adapted.

Compare the code in the server.js file in these two application examples.



* [1cloudfoundry_base](https://github.com/IBM-Cloud/CloudFoundry-to-CodeEngine/tree/1cloudfoundry_base)
* [3codeengine_target](https://github.com/IBM-Cloud/CloudFoundry-to-CodeEngine/tree/3codeengine_target)







 Staging your application migration 

If your application cannot be down while you move it from Cloud Foundry to Code Engine, consider performing the code migration with an intermediate step.



* [1cloudfoundry_base](https://github.com/IBM-Cloud/CloudFoundry-to-CodeEngine/tree/1cloudfoundry_base): The Cloud Foundry code base as the initial source. This app runs only in Cloud Foundry.
* [2cf_ce_intermediate_hybrid](https://github.com/IBM-Cloud/CloudFoundry-to-CodeEngine/tree/2cf_ce_intermediate_hybrid): Add code to also support a Code Engine deployment. This application runs in both Cloud Foundry and Code Engine.
* [3codeengine_target](https://github.com/IBM-Cloud/CloudFoundry-to-CodeEngine/tree/3codeengine_target): Finally, move to a Code Engine-only code base after the actual project migration is completed. This application runs only in Code Engine.



This approach is beneficial because you can continue to maintain or enhance the code base during the migration process, independently of the deployment environment.





 Building your code and running your app 

When you are finished setting up your service bind, migrating your code, and preparing to stage your migration, it is time to build your code.
Configuring multiple apps on one CI toolchain 

When you run service offerings through Continuous Integration (CI), consider consolidating all of your offering's micro-services or components into a single common Toolchain, rather than managing multiple toolchains for each repo.

Configuring the [CI Pipeline](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-ci-pipeline) and [pull request (PR) pipeline](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-pr-pipeline) to work for multiple applications' repositories is simple. Use the following steps and changes to enable multiple applications.



 Toolchain changes 

Follow these steps:



1. Add a GitHub Tool integration for each application that you want to build on the toolchain pipelines.
2. Add more GitHub integrations for any extra [issue](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-incident-issues), [inventory](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-inventory), and [evidence](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-evidence) repositories that can be configured for certain applications.



* Refer to the documentation pages and best practices to understand if you need these extra repositories for the applications.
* One inventory and issues repository should be enough, but you might want to have a different evidence repository for each application due to how "inhumanly" readable the repository structure is. And a separate repo helps you to know which application you're looking at.
* The Application repos can also serve as its own issues repo. That is, if the GitHub issues option is enabled on the tool integration.
If this change was intentional, you must first determine whether your apps can run with the [cluster role binding](https://cloud.ibm.com/docs/containers?topic=containers-ts-app-pod-securitycreate-privileged-psp-user). If they can, Create or update restricted-psp-user [cluster role binding](https://cloud.ibm.com/docs/containers?topic=containers-ts-app-pod-securitycreate-restricted-psp-user).





 Could not get ClusterRoleBinding restricted-psp-user 

This message indicates the restricted-psp-user cluster role binding does not exist or some other error prevented the upgrade operation from reading the resource.



1. Get the details of the restricted-psp-user cluster role binding.

kubectl get clusterrolebindings restricted-psp-user
2. If you get a NotFound error, create or update restricted-psp-user [cluster role binding](https://cloud.ibm.com/docs/containers?topic=containers-ts-app-pod-securitycreate-restricted-psp-user).







 ClusterRoleBinding restricted-psp-user does not have expected roleRef 

This error indicates is an unexpected change and that the cluster role binding is referencing the wrong cluster role.

Complete the following steps to change the roleRef.



1. Delete the cluster role binding.

kubectl delete clusterrolebinding restricted-psp-user
2. Create or update restricted-psp-user [cluster role binding](https://cloud.ibm.com/docs/containers?topic=containers-ts-app-pod-securitycreate-restricted-psp-user).







 ClusterRoleBinding restricted-psp-user does not have expected subjects 

If this change was intentional, you must first determine if applications can run properly with the [cluster role binding](https://cloud.ibm.com/docs/containers?topic=containers-ts-app-pod-securitycreate-restricted-psp-user).
The tables in [Supported previous-generation language models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-modelsmodel-pg-supported) list the recommended next-generation model to which to migrate from a previous generation model. Use the indicated next-generation model in your speech recognition requests.

The service continues to make new next-generation models available. All new models are identified in the release notes and in the tables that describe the available models.

Optimally, you migrate from a narrowband model to a next-generation telephony model, and from a broadband model to a next-generation multimedia model. However, not all broadband models have equivalent multimedia models. In such cases, you can migrate from a broadband model to a telephony model. The service downsamples the audio that you send to the rate of the model that you use. So sending broadband audio to a telephony model might prove a sufficient alternative in cases where no equivalent multimedia model is currently available.

For example, the following speech recognition request uses the previous-generation en-US_NarrowbandModel:

curl -X POST -u "apikey:{apikey}" --header "Content-Type: audio/flac" --data-binary @{path}audio-file.flac "{url}/v1/recognize?model=en-US_NarrowbandModel"

To use the equivalent next-generation en-US_Telephony model, you simply change the value that you pass with the model query parameter:

curl -X POST -u "apikey:{apikey}" --header "Content-Type: audio/flac" --data-binary @{path}audio-file.flac "{url}/v1/recognize?model=en-US_Telephony"





 Step 2: Identify the features that are available with next-generation models 

Next-generation models support slightly fewer features and parameters than previous-generation models. However, although they lack full parity, most features are available with both types of models. And where a feature is limited to a subset of languages, the limitations apply equally to both types of models.
* Understand how to identify microservices in a VM based app and learn how to map components between VMs and Kubernetes.
* Learn how to containerize a VM based app.
* Learn how to deploy the container to a Kubernetes cluster in Kubernetes Service.
* Put everything learned to practice, run the JPetStore app in your cluster.







 Architecture 



 Traditional app architecture with VMs 

The following diagram shows an example of a traditional app architecture that is based on virtual machines.

Zoom

![Diagram of traditional app architecture](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution30/traditional_architecture.png)

Figure 1. Architecture diagram of the tutorial



1. The user sends a request to the public endpoint of the app. The public endpoint is represented by a load balancer service that load balances incoming network traffic between available app server instances.
2. The load balancer selects one of the healthy app server instances that run on a VM and forwards the request. App files, such as the app code, configuration files, and dependencies are stored on the app server VM.
3. The app server stores app data in a MySQL database that runs on a database VM.







 Containerized architecture 

The following diagram shows an example of a modern container architecture that runs in a Kubernetes cluster.

Zoom

![Diagram of a modern container architecture](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution30/modern_architecture.png)

Diagram of a modern container architecture



1. The user sends a request to the public endpoint of the app.
: See [Choosing a build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy).





 13 June 2023 

Added troubleshooting information about deleting jobs and job runs when the limit is exceeded
: See [I'm over my limit for jobs or job runs. How can I delete them](https://cloud.ibm.com/docs/codeengine?topic=codeengine-ts-jobrun-deleteforquota)?

Updated versions for buildpacks
: See [Choosing a build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy).





 08 June 2023 

CLI version 1.43.7 released
: See [CLI version history](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli_versions).





 01 June 2023 

Added troubleshooting information about stopping an app from receiving traffic
: See [Can I stop my app](https://cloud.ibm.com/docs/codeengine?topic=codeengine-ts-app-stop-traffic)?

Updated information about working with multi-line log data
: See [Considerations for viewing logs from the console](https://cloud.ibm.com/docs/codeengine?topic=codeengine-view-logsview-logs-considerations).







 May 2023 

Review the release notes for May 2023.



 30 May 2023 

Added support to get status details for a project in the Code Engine V2 API
: See [API change log](https://cloud.ibm.com/docs/codeengine?topic=codeengine-api-changelog).





 25 May 2023 

Updated versions for buildpacks
: See [Choosing a build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy).

Updated information about DDoS protection in Code Engine
You can use Gradle to fetch and build a final .jar archive that includes your code and all dependencies.

The following example uses Gradle to build a Java action that leverages the library com.google.zxing that provides the functionality to generate a QR code image.



1. Create a file that is named build.gradle and specify the dependencies.

apply plugin: 'java'

version = '1.0'

repositories {
mavenCentral()
}

configurations {
provided
compile.extendsFrom provided
}

dependencies {
provided 'com.google.code.gson:gson:2.9.0'
compile 'com.google.zxing:core:3.3.0'
compile 'com.google.zxing:javase:3.3.0'
}

jar {
dependsOn configurations.runtime

from {
(configurations.runtime - configurations.provided).collect {
it.isDirectory() ? it : zipTree(it)
}
}
}
Show more
2. Run the command gradle jar, which generates a .jar archive in the directory build/libs/.



For more information, read the Gradle documentation [Declaring Dependencies](https://docs.gradle.org/current/userguide/declaring_dependencies.htmldeclaring_dependencies).





 Packaging Java code by using the Java runtime with Docker 

Package your code with Docker by creating a .jar file inside the Java runtime.

Before you begin, you must have Docker installed locally.

You won´t need Java installed locally as everything is supplied by the Java runtime.

To create a Java action by using Docker, complete the following steps.



1. Create Hello.java file

import com.google.gson.JsonObject;

public class Hello {
public static JsonObject main(JsonObject args) {
String name = "stranger";
However, do not attempt to upgrade multiple peers or multiple ordering nodes at the same time, as this threatens the availability of your components.

It is not possible to upgrade an ordering node if any node in your ordering service is down for any reason. Coordinate with all of the administrators of your ordering service before attempting to upgrade.





 Step three: Update SDKs and smart contracts 

It is a best practice to upgrade your SDK to the latest version as part of a general upgrade of your network. While the SDK will always be compatible with equivalent releases of Fabric and lower, it might be necessary to upgrade to the latest SDK to leverage the latest Fabric features. Also, after upgrading, it's possible your client application may experience errors. Consult the your Fabric SDK documentation for information about how to upgrade.

Although support for Fabric 2.0 networks was added to the platform, you can still run your existing smart contracts on your peers that run a v1.4 image on a channel with an application capability level of 1.4 or lower. Should you later decide to upgrade your peer to a v2.x image and update your channel application capability level to 2.0, you may need to update your existing smart contract. However, after you upgrade your peer image to v2.x and channel application capability v2.x, there is no longer a way to update the original smart contract. Instead, when an update is required, you need to repackage the smart contract in the new .tar.gz or .tgz format using v2 of the VS Code extension and then propose the definition to the channel using the new smart contract lifecycle process.

Review the following considerations:

Node

If your smart contract was written in Node, then you might need to update it. By default, a Fabric v1.4 peer will create a Node v8 runtime, and a Fabric v2.x peer creates a Node v12 runtime. In order for a smart contract to work with Node v12 runtime, the fabric-contract-api and fabric-shim node modules must be at v1.4.5 or greater.
(https://cloud.ibm.com/docs/faqsfaq-ac-metrics) Rely on your own domain knowledge, business metrics, and usage forecasts to predict cost.
* Can you give some example pricing scenarios?



 Pricing Scenario 1: Mobile App with Feature Flags 

Assume you have a mobile app and you want feature flags and targeted segments to roll out features incrementally to different sets of users. Your historical metrics show 200,000 users but only about 50% are active in a month. An average active user opens the app or brings it to the foreground once every day. You expect to roll out a new feature twice per month.

You need the App Configuration Enterprise plan to support both feature flags and segmentation.

For this example, assume an Enterprise plan instance is $500 per month, active entity IDs are $0.01 each, and API calls are $10 per 100,000. NOTE: These prices are assumed for this example only. Current pricing may be different from the amounts shown in the example. See the App Configuration catalog page for current pricing.

App Configuration Enterprise instances: 1 @ $500 per month Active Entity IDs: 200,000 total app instances (users) * 50% active = 100,000 Included Active Entity IDs: 10,000 Net Active Entity IDs: 100,000 - 10,000 = 90,000 @ $0.01 per Active Entity ID = $900

API Calls: 100,000 Active Entity IDs * 30 app invocations per month = 3,000,000 Included API Calls: 1,000,000 Net API Calls: 3,000,000 - 1,000,000 = 2,000,000 @ $10/ 100,000 API Calls = $200 TOTAL COST: $500 + $900 + $200 = $1600 per month





 Pricing Scenario 2: Microservice with Feature Flags 

Assume you have five backend microservices that support your mobile app. To fully test new microservice features, you want to dark launch them into production and target them only to testers. The mobile app is used worldwide, so you have the set of five microservices in each of 3 regions worldwide, and you want to test in your app in each region before going live.
This must be done before calling the init function on the SDK.





 Option to use a persistent cache for configuration 

In order for your application and SDK to continue its operations during the unlikely unavailability of the App Configuration service across your application restarts, you can configure the SDK to use a persistent cache. The SDK uses the persistent cache to store App Configuration data that is available across your application restarts.

// 1. default (without persistent cache)
appConfigClient.setContext(collectionId, environmentId)

// 2. optional (with persistent cache)
appConfigClient.setContext(collectionId, environmentId, {
persistentCacheDirectory: '/var/lib/docker/volumes/'
})

Where:



* persistentCacheDirectory: Absolute path to a directory, which has read and write permission for the user. The SDK creates a file - appconfiguration.json in the specified directory, and it is used as the persistent cache to store the App Configuration service information.

When persistent cache is enabled, the SDK keeps the last known good configuration in the persistent cache. If the App Configuration server is unreachable, the most recent configurations in the persistent cache are loaded to the application to continue working.



Make sure that the cache file is not lost or deleted in any case. For example, consider the case when a Kubernetes pod is restarted and the cache file (appconfiguration.json) was stored in ephemeral volume of the pod. As pod gets restarted, Kubernetes destroys the ephermal volume in the pod, as a result the cache file gets deleted. So, make sure that the cache file created by the SDK is always stored in persistent volume by providing the correct absolute path of the persistent directory.





 Offline options 

The SDK is also designed to serve configurations, perform feature flag and property evaluations without being connected to App Configuration service.

appConfigClient.setContext(collectionId, environmentId, {
bootstrapFile: 'saflights/flights.json',
For more information, see [Managing rolling deployments to update your apps](https://cloud.ibm.com/docs/openshift?topic=openshift-update_appapp_rolling).

Instantaneous switch
: Also referred to as a blue-green deployment, an instantaneous switch requires double the compute resources to have two versions of an app running at once. With this approach, you can switch your users to the newer version in near real time. Make sure that you use service label selectors (such as version: green and version: blue) to make sure that requests are sent to the correct app version. You can create the new version: green deployment, wait until it is ready, and then delete the version: blue deployment. Or you can perform a [rolling update](https://cloud.ibm.com/docs/openshift?topic=openshift-update_appapp_rolling), but set the maxUnavailable parameter to 0% and the maxSurge parameter to 100%.

Canary or A/B deployment
: A more complex update strategy, a canary deployment is when you pick a percentage of users such as 5% and send them to the new app version. You collect metrics in your logging and monitoring tools on how the new app version performs, do A/B testing, and then roll out the update to more users. As with all deployments, labeling the app (such as version: stable and version: canary) is critical.





 How can I automate my app deployment? 

If you want to run your app in multiple clusters, public and private environments, or even multiple cloud providers, you might wonder how you can make your deployment strategy work across these environments. With IBM Cloud and other open source tools, you can package your application to help automate deployments.

Set up a continuous integration and delivery (CI/CD) pipeline
: With your app configuration files organized in a source control management system such as Git, you can build your pipeline to test and deploy code to different environments, such as test and prod. Work with your cluster administrator to [set up continuous integration and delivery](https://cloud.ibm.com/docs/openshift?topic=openshift-cicd).
This process is not required for smart contracts that are written in Java or Node.js, nor for Go smart contracts that use the [Go contract-api](https://github.com/hyperledger/fabric-contract-api-go).

Java
The build.gradle file for the smart contract must be updated:



1. If the smart contract uses the shadowjar 2.x plugin, then it should be updated to version 5 by using the following code:

plugins {
id 'com.github.johnrengelman.shadow' version '5.1.0'
id 'java'
}
2. The repositories section of the file must contain the maven URL for jitpack, for example:

repositories {
...
maven {
url 'https://jitpack.io'
}
}



Init functions

If the smart contract was written using the low-level APIs provided by the Fabric Chaincode Shim API, your smart contract needs to contain an Init function that is used to initialize the chaincode. This function is required by the smart contract interface, but does not necessarily need to be invoked by your applications. Because you cannot use the console to deploy a smart contract that contains an Init function, you need to move that initialization logic into the smart contract itself and call it separately. For example, the smart contract can use a reserved key to check whether the smart contract has already been initialized or not. If not, then call the initialization logic, otherwise proceed as usual. If your smart contract needs to include the Init function, the only way to deploy it is by using the Fabric [peer lifecycle chaincode install](https://hyperledger-fabric.readthedocs.io/en/release-2.2/commands/peerlifecycle.htmlpeer-lifecycle-chaincode-install) command or the [IBM Blockchain Platform collection for Ansible](https://ibm-blockchain.github.io/ansible-collection/).