vania-janet/multiturn-rag-retrieval-data huggingface dataset:
A higher rate causes the text to be spoken more quickly; a lower rate causes the text to be spoken more slowly. The parameter changes the per-voice default rate for an entire request. For more information, see [Modifying the speaking rate](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-synthesis-paramsparams-rate-percentage).

New beta pitch_percentage query parameter for controlling the global speaking pitch
: The service offers a new pitch_percentage query parameter to modify the speaking pitch for a synthesis request. The speaking pitch represents the tone of the speech that the service synthesizes. It represents how high or low the tone of the voice is perceived by the listener. A higher pitch results in speech that is spoken at a higher tone and is perceived as a higher voice; a lower pitch results in speech that is spoken in a lower tone and is perceived as a lower voice. The parameter changes the per-voice default pitch for an entire request. For more information, see [Modifying the speaking pitch](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-synthesis-paramsparams-pitch-percentage).

Defect fix: Japanese synthesis is improved to handle long strings of input text
: Defect fix: The service now correctly synthesizes Japanese requests that include long strings of characters. Previously, the service failed to properly synthesize very long strings of Japanese text.

Documentation updates for the SSML <prosody> element
: The documentation for the SSML <prosody> element and its pitch and rate parameters has been improved and clarified. It also now includes a description of the differences between the service and the latest version of the SSML specification. For more information, see [The <prosody> element](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-elementsprosody_element).





 3 August 2022 

The service does not support multilingual speech synthesis
: The service does not support multilingual speech synthesis at this time. However, you can use customization to approximate the pronunciation of words from other languages.
The changes are applied to your ALBs automatically.
4. Verify that the ConfigMap changes were applied.

kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml







 Changing the number of simultaneous connections or worker processes 

Change the default setting for how many simultaneous connections the NGINX worker processes for one ALB can handle or how many worker processes can occur for one ALB.

Each ALB has NGINX worker processes that process the client connections and communicate with the upstream servers for the apps that the ALB exposes. By changing the number of worker processes per ALB or how many connections the worker processes can handle, you can manage the maximum number of clients that an ALB can handle. Calculate your maximum client connections with the following formula: maximum clients = worker_processes * worker_connections.



* The max-worker-connections field sets the maximum number of simultaneous connections that can be handled by the NGINX worker processes for one ALB. The default value is 16384. Note that the max-worker-connections parameter includes all connections that the ALB proxies, not just connections with clients. Additionally, the actual number of simultaneous connections can't exceed the [limit on the maximum number of open files](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsmax-worker-files), which is set by the max-worker-open-files parameter. If you set the value of max-worker-connections to 0, the value for max-worker-open-files is used instead.
* The worker-processes field sets the maximum number of NGINX worker processes for one ALB. The default value is "auto", which indicates that the number of worker processes matches the number of cores on the worker node where the ALB is deployed. You can change this value to a number if your worker processes must perform high levels of I/0 operations.





1. Edit the ibm-k8s-controller-config ConfigMap.

kubectl edit cm ibm-k8s-controller-config -n kube-system
2.
description string The text of the description that accompanies the image. N 







 Example 

This example displays an image with a title and descriptive text.

{
"output": {
"generic":[
{
"response_type": "image",
"source": "http://example.com/image.jpg",
"title": "Example image",
"description": "An example image returned as part of a multimedia response."
}
]
}
}







 Option 

Displays a set of buttons or a drop-down list users can use to choose an option. The specified value is then sent to the workspace as user input.



 Fields 



 Name Type Description Required? 

 response_type enum option Y 
 title string The title to show before the options. Y 
 description string The text of the description that accompanies the options. N 
 preference enum The preferred type of control to display, if supported by the channel (dropdown or button). The Watson Assistant connector currently supports only button. N 
 options list A list of key/value pairs specifying the options from which the user can choose. Y 
 options[].label string The user-facing label for the option. Y 
 options[].value object An object defining the response that will be sent to the Watson Assistant service if the user selects the option. Y 
 options[].value.input object An input object that includes the input text corresponding to the option. N 
 options[].value.input.text string The text that will be sent to your assistant for the option. N 







 Example 

This example displays two options:



* Option 1 (labeled Buy something) sends a simple string message (Place order), which is sent to the workspace as the input text.
* Option 2 (labeled Exit) sends a complex message that includes both input text and an array of intents. The response can include any field that is a valid part of a Watson Assistant message.
It is a good idea to enable this retry feature because the alternative is that your application code must perform any retries itself. The combination of batching in Kafka and automatic retries can have the effect of duplicating messages and reordering them.

For example, if you publish a sequence of three messages <M1, M2, M3> on a topic. The records might all fit within the same batch, so they're all sent to the partition leader together. The leader then writes them to the partition and replicates them as separate records. If a failure occurs, it is possible that M1 and M2 are added to the partition, but M3 is not. The producer doesn't receive an acknowledgment, so it retries sending <M1, M2, M3>. The new leader writes M1, M2 and M3 onto the partition, which now contains <M1, M2, M1, M2, M3>, where the duplicated M1 follows the original M2. If you restrict the number of requests in flight to each broker to just one, you can prevent this reordering. You might still find that a single record is duplicated such as <M1, M2, M2, M3>, but you never get out of order sequences. In Kafka version 0.11 or later, you can also use the idempotent producer feature to prevent the duplication of M2.

It is normal practice with Kafka to write the applications to handle occasional message duplicates because the performance impact of having only a single request in flight is significant.





 Message acknowledgments 

When you publish a message, you can choose the level of acknowledgments that are required by using the acks producer configuration. The choice represents a balance between throughput and reliability. The following three levels exist.

acks=0 (least reliable)
: The message is considered sent as soon as it was written to the network. There is no acknowledgment from the partition leader. As a result, messages can be lost if the partition leadership changes. This level of acknowledgment is fast, but comes with the possibility of message loss in some situations.

acks=1 (the default)
* Concurrency = 2



With these settings, your app can process 2 concurrent requests at the same time. When there is no traffic, your application automatically scales down to 4 instances. The 4 instances can handle only 4 * 2 (currency) = 8 requests. The application can scale up to a maximum of 20 instances, such that the 20 instances can handle 20 * 2(currency) = 40 requests, assuming sufficient CPU and memory settings for the application.

Suppose that your application is a static web application that requires 6 calls to your application to load a login page. Assume that 10 people log in to your application login page at the same time (10 * 6 = 60 calls). Because 60 calls ares greater than 40 requests that can be handled by your app, users of the application likely observe slowness as the calls are queued.

After about a minute of no traffic against your app, Code Engine starts to automatically scale down. When your application scales down, some instances are set in Terminating status. Code Engine sends a SIGTERM signal to your application and your code must handle this signal and shut down. If your application does not handle this signal, your app instances stay in Terminating status for the time that is configured by the request timeout value (default value is 300 seconds). After the duration of the request timeout, Code Engine sends a SIGKILL signal to forcefully stop the app instances in Terminating status.

If you have 8 active instances and 12 instances stay in Terminating status for 300 seconds (5 minutes). These 12 instances do not receive any requests. If more than 8 * 2 (currency) = 16 requests come in, then Code Engine scales up new instances.

In this example, the concurrency value of 2 is low for this static content. You must determine the autoscaling values to set for your app, which depends on what the implementation of your app can handle with its assigned CPU and memory resources.







 Optimize latency and throughput 

To optimize your application latency and throughput, understand the pros and cons of some common models and best practices to configure the container concurrency.

Use the setting for concurrency to specify the maximum number of requests that can be processed concurrently per instance when you create or update an application.
In a future release blueprints will provide the option to preview the resources that will be deleted.
2. The user initiates a destroy of the cloud resources that belong to the blueprint environment. The blueprint destroy operation iterates through all the blueprint modules, destroying resources in reverse dependency order to ensure that all cloud resources are cleanly removed. On resource destroy, all the modules return to an Inactive state to indicate that no cloud resources remain. For more information, see [Destroy a blueprint environment](https://cloud.ibm.com/docs/schematics?topic=schematics-destroy-blueprint). When the resources get destroyed, billing gets terminated.



* Optional: A fresh instance of the environment can be deployed from the saved IBM Cloud® Schematics Blueprint configuration by running the [blueprint apply](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-cli-reference&interface=clischematics-blueprint-apply) operation to re-create the environment and cloud resources.



3. For each module, Schematics runs a Terraform Destroy to delete all the cloud resources created by the module.
4. The blueprint modules and blueprint configuration are deleted from Schematics using the delete operation. It is only enabled if all the resources are already destroyed and the modules are in an Inactive state. For more information, see [blueprint delete](https://cloud.ibm.com/docs/schematics?topic=schematics-delete-blueprint).



The blueprint environment and cloud resources are now deleted.



 Next steps 



* You can explore more by using the [blueprint tutorials](https://cloud.ibm.com/docs/schematics?topic=schematics-deploy-schematics-blueprint-cli&interface=cli).
Getting started with IBM security groups 

You can use security groups to enact a set of IP filter rules that define how to handle incoming and outgoing traffic to both the public and private interfaces of a virtual server instance.

To get started, order a virtual server instance and assign a security group.



1. From your browser, open the [IBM Cloud catalog](https://cloud.ibm.com/catalog) and log in to your account.
2. Select Services > Compute, then click the Virtual Server for Classic tile to show the Virtual server instance page.
3. Configure your virtual server based on your requirements.

For more information, see [Getting started with virtual servers](https://cloud.ibm.com/docs/virtual-servers).
4. In the Network Interface section, use the menus to select any predefined private or public security groups for your virtual server instance.

Only predefined security groups show in these menu lists. To define a new security group, see [Creating security groups and rules](https://cloud.ibm.com/docs/security-groups?topic=security-groups-creating-security-groups).
5. Click Create.





 Use cases and solutions 

The following sections describe a few difficult network security scenarios that can be alleviated by using security groups.



 Security from the start 

Security scenario: You want to secure your virtual server as soon as it is provisioned. You also want complete control over the traffic that passes through the server from the point when it was provisioned.

Solution: Use security groups when you order a virtual server. That way, your server is protected when it is first provisioned.





 Cost-efficient instance level firewall 

Security scenario: Customers want granular control over traffic at an instance level (apart from network-level firewalls). However, at the same time, the costs of a shared hardware firewall can add up quickly if you need to protect multiple servers in different data centers.

Solution: You do not incur extra charges for using security groups. You can use security groups for all virtual servers that need protection in any of our global data centers.





 Globally scalable and easily manageable firewall
In the Shared Cluster deployment, IBM Red Hat OpenShift on IBM Cloud and IBM Cloud Pak for Data will be shared across multiple Production Instance(s) and Non-Production Instance(s) and Clients.

The provisioning itself can be broken down into a number of steps:



1. Order validation
2. Information gathering
3. Initial provisioning of TAS base environment
4. Provisioning of the individual TAS products the clients has requested
5. Internal IBM verification of the provisioned environments
6. Welcome letter sent to the client / designated contacts indicating provisioning is complete







 Order Validation 

Once an order has been placed, the initial step is to validate the order and the information submitted. This includes checking the part numbers, ensuring the provisioning form has been completed, performing IBM internal financial checks and setting up the order to be provisioned. In general this can take 1 to 2 days to complete.

Once this is complete, the order is sent to the IBM TAS Managed Services Provisioning team to begin the provisioning of the order.





 Information Gathering 

Once the order has been placed into the provisioning queue, additional information needs to be validated and gathered. This includes preparing the final architecture for the order; specifying the infrastructure needed to meet the order requirements; ensuring requested URL(s) are valid and available; detailed review of the order to ensure completeness; meeting or clarifying specific items with the sales person or client as required and setting up the provisioning parameters.

This step can take a few hours to several days depending on the initial quality and completeness of the information. Critical information that is needed includes:



* products that to be deployed (not all products will be deployed by default).
* anticipated sizing information for each product - this can be based on users, I/O or other metrics specific to each product
* URL's being requested
* Languages required
* Add On and/or Industry Solutions required
* location of the majority of users to determine optimal placement of the Suite in the proper IBM Cloud data center



If this information is missing or incorrect it can cause delays in the provisioning process while this information is being confirmed.





 Initial Provisioning
- host: <custom_ingress_domain>
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginxsvc
port:
number: 80
Show more
6. Create the Ingress resource in your cluster.

kubectl apply -f dl-ingress-resource.yaml -n dl-reverse-proxy



The private Ingress ALBs in your cluster are now configured to expose a reverse proxy service with your custom domain on the IBM Cloud private network.





 Step 3: Deploy an NGINX reverse proxy 

Deploy an NGINX reverse proxy in the cluster that is exposed on the private network by the Ingress ALBs, and configure the reverse proxy to point to the Satellite Link tunnel server for your location.

The following steps include editing and using local YAML files to create a ConfigMap, an NGINX deployment, and a service. As an alternative, you can clone an NGINX HTTPS sample repository, such as the [https-nginx directory of the kubernetes/examples repository](https://github.com/kubernetes/examples/tree/master/staging/https-nginx), and [push the Docker image to a namespace in IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started). If you use a sample repository, ensure that the NGINX configuration, such as in the default.conf file, includes the server block that is specified in step 2 of this section.



1. Get the private service endpoint for the Link tunnel server. In the output, look for the Address that is listed for an endpoint of type location.

ibmcloud sat endpoint ls --location <location_ID>

In this example output, the tunnel server endpoint is c-04.private.us-east.link.satellite.cloud.ibm.com. Do not include a port.

ID Name Destination Type Address
The information includes specifying the number of pods, the number of CPUs allocated per pod, and the maximum number of concurrent sessions with previous- and next-generation models. For more information, see [Administering Watson Speech to Text](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=text-administering-watson-speech).

Command-line updates to import and export utilities
: The commands that are used with the import and export utilities for the Speech services include new options and arguments. The import and export utilities are also the foundation for backing up and restoring the services and for migrating from IBM Cloud Pak for Data version 3.5 to version 4.0.3. For more information about using the utilities, see



* [Administering Watson Speech to Text](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=text-administering-watson-speech)
* [Upgrading Watson Speech to Text](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=text-upgrading-watson-speech)



New property for specifying the CPUs for acoustic model training
: The sttAMPatcher microservice manages acoustic model customization for the service. The AM Patcher uses a dedicated number of CPUs to handle requests. You can use the new sttAMPatcher.resources.requestsCPU property to increase the number of CPUs that are dedicated to handling acoustic model training requests by the AM Patcher. This may be necessary if you experience training failures during acoustic model training. For more information, see [Installing Watson Speech to Text](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=text-installing-watson-speech).

New next-generation models
: The service now supports the following new next-generation language models. All of the new models are generally available.



* Czech: cs-CZ_Telephony. The model supports low latency.
* Belgian Dutch (Flemish): nl-BE_Telephony.
You can scale up or down, by selecting a smaller or larger configuration, according to your needs.

The IBM Blockchain Platform deployer attempts to spread peers, ordering nodes, and CA replica sets across different worker nodes but cannot guarantee that it will happen due to resource limitations. You can also use the IBM Blockchain Platform APIs or the blockchain console to deploy peers or ordering nodes to specific zones in order to ensure that they are resilient to a zone failure. For more information see [Multizone HA](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-haibp-console-ha-multi-zone).





 Potential points of failure 

IBM Blockchain Platform offers several approaches to add more availability to your network by adding redundancy and using anti-affinity policies. Review the following diagrams to learn more about potential points of failure and how to eliminate them. You can select a model based on your application criticality, service levels, and costs. As general rule, you can implement the redundancy to meet your service levels. All of these scenarios must be weighed against the cost of implementing greater resiliency.



 Single region HA 

Zoom

![Blockchain HA single region options](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/HA_Diagram-1.svg)

Figure 1. Blockchain HA single region options



1. Component failure.

Single-zone cluster:

Every time that you deploy a blockchain component, such as a peer, ordering node, or CA, a new pod is created for the component in a worker node. Containers and pods are, by design, short-lived and can fail unexpectedly. For example, a container or pod might crash if an error occurs in your component. So, to make your node highly available, you must ensure that you have enough instances of it to handle the workload plus extra instances in case of a failure.

Peers How many peers are required?
To make a slot conditional, edit the slot, and then from the More![More icon](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/kebab.png) menu, select Enable condition. Define the condition that must be met for the slot to be enabled.

You can condition on the value of a context variable from an earlier slot because the order in which the slots are listed is the order in which they are evaluated. However, only condition on a slot context variable that you can be confident will contain a value when this slot is evaluated. The earlier slot must be a required slot, for example.



7. Keep users on track. You can optionally define slot handlers that provide responses to questions users might ask during the interaction that are tangential to the purpose of the node.

For example, the user might ask about the tomato sauce recipe or where you get your ingredients. To handle such off-topic questions, click the Manage handlers link and add a condition and response for each anticipated question.

![Shows a user ask about the sauce recipe. The response is, I'll take it to my grave'.](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/sauce.png)

After responding to the off-topic question, the prompt associated with the current empty slot is displayed.

This condition is triggered if the user provides input that matches the slot handler conditions at any time during the dialog node flow up until the node-level response is displayed. See [Handling requests to exit a process](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-slotsdialog-slots-node-level-handler) for more ways to use the slot handler.
8. Add a node-level response.