vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To get a full list of zones within a region, see [Get zones by using the CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-in-a-different-regionget-zones-using-the-cli). 







 Parameters for auto scaling 

You can set the following parameters for auto scaling:



* worker_node_min_count: The minimum number of worker nodes that are provisioned at the time the cluster is created and remain running regardless of job demands in the cluster.
* worker_node_max_count: The maximum number of worker nodes in your HPC cluster, which limits the number of machines that can be added to HPC cluster. LSF auto scaling scales up the cluster to this number of nodes when needed for your workloads and scales back for keeping onlyworker_node_min_count workers when no job is in the queues.







 Parameters for instance profiles 

You can control the instance profile for each instance type through the xxx_node_instance_type parameters. The management nodes are where the main LSF daemons are running. You need to select ones with more compute power if you plan to run jobs by using 100+ nodes. The worker nodes are the ones where the workload execution takes place and the choice needs to be made according to the characteristic of workloads. The storage node is the one to manage the NFS file system for your HPC cluster. The login instance is served as a jump host, so you can pick the smallest profile. For more information, see [Instance Profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles).





 Parameters for block volumes 

You can configure the storage capacity and throughput by using the volume_xxx parameters. The value for the volume_profile parameter can be either general purpose or custom. When general-purpose is used, IOPS is determined by the cloud infrastructure and the volume_iops parameter does not have any effect. If you want to customize the IOPS, you need to use custom for volume_profiles and set up the IOPS through volume_iops based on the capacity that is specified in volume_capacity.
Yes 
 sign-artifact Signs the built artifacts. Yes 
 deploy Deploys the configuration, by using the built artifacts, to the dev environment. Yes 
 acceptance-test Runs acceptance and integration tests on the deployed configuration on the dev environment. Yes 
 release Adds the built artifacts to the inventory. Yes 
 finish Collects, creates, and uploads the logs files, artifacts, and evidence to the evidence locker. No 



For more information about how to customize stages by using the .pipeline-config.yaml file, see [Custom scripts](https://cloud.ibm.com/docs/devsecops?topic=devsecops-custom-scripts) and [Pipeline parameters](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-pipeline-parmcd-ci-parameters) lists.





 Parameters to configure Terraform context and variables 

For Terraform definitions that define infrastructure-as-code source, the context and variables that are related to Terraform and Terraform-related scan and checks can be defined by using the parameters that are described in Table 1.



Table 2. Parameters to configure Terraform context and variables

 Property Default Description 

 tf-dir . Location or path in the source repository where main.tf is located. 
 TF_VAR_<XXXX> Pipeline or trigger property (secured or unsecured) that provides the value for Terraform variable <XXXX> 
 tfvars-repository Infrastructure source code Git repository. Git repository that contains tfavars files. The repository must be declared in the toolchain. 
 tfvars-branch main Branch of the Git repository that contains the tfvars files. 
 tfvars-files Files that contain Terraform variables values. 
 terraform-version 1.2.9 Terraform CLI tool version to install if not present in the image used for the stages. 



The same parameters apply for the scripts that are used in an IaC CD deployment process. Because the CD process can process multiple inventory entries, you can scope a parameter for an inventory entry.
IBM Cloud Pak for Data

curl -X POST --header "Authorization: Bearer {token}" --header "Content-Type: audio/flac" --data-binary @{path}audio-file.flac "{url}/v1/recognize?smart_formatting=true"







 Numeric redaction 

The numeric redaction feature is beta functionality that is available for US English, Japanese, and Korean.

The redaction parameter directs the service to redact, or mask, numeric data from final transcripts. The feature redacts any number that has three or more consecutive digits by replacing each digit with an X character. It is intended to redact sensitive numeric data, such as credit card numbers.

By default, the service does not redact numeric data. Set the redaction parameter to true to enable numeric redaction. When you enable redaction, the service automatically enables smart formatting by setting the smart_formatting parameter to true, regardless of whether you explicitly disable that feature. To ensure maximum security, the service also disables the following parameters when you enable redaction:



* The service disables keyword spotting, regardless of whether you specify values for the keywords and keywords_threshold parameters.
* The service disables maximum alternatives, regardless of whether you specify a value greater than 1 for the max_alternatives parameter. The service returns only a single final transcript.
* The service disables interim results for the WebSocket interface, regardless of whether you set the interim_results parameter to true.



The design of the feature parallels the existing smart formatting feature. The service applies redaction only to the final transcript of a recognition request, just before it returns the results to the client and after text normalization is complete.



 Language differences 

The feature works exactly as described for US English models but has the following differences for Japanese and Korean models.



 Japanese 

Japanese redaction has the following differences:



* In addition to masking strings of three or more consecutive digits, redaction also masks street addresses and numbers, regardless of whether they contain fewer than three digits.
* Similarly, redaction also masks date information in Japanese-style birth dates.
A blueprint config links a template with the set of inputs values to customize the environment and cloud resources for its target use. The config its relationship to a template and input files are illustrated in the figure below.





 Blueprint template overview 

The infrastructure architecture of a solution is defined by a blueprint template:



* Blueprint templates are written in YAML with a minimum of syntax that specify the automation modules to be used, their versions, source libraries, and relationships for passing resource dependency data between modules.
* The resource management and provisioning functionality of a blueprint is implemented by automation modules written for the familiar open source Terraform automation tool.
* Input variable files customize the reusable blueprint templates to create cloud environments.



This structure and relationship between inputs, modules and template are illustrated in the figure.

Zoom

![Blueprint config linking a template and inputs](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics//images/new/bp-configuration.svg)

Blueprint config linking a template and inputs

The blueprint config defines the source of the versioned blueprint template in source control and the input files to customize the blueprint. Also additional parameters for naming the blueprint, blueprint access control and additional inputs.

The template file contains module definitions specifying the required Terraform modules and their source location. The module definitions define the dependencies between modules for passing resource data. These also define the deployment order to ensure that resource dependencies are satisfied before module provisions.



 Blueprint template YAML file 

The text box shows a simplified view of a blueprint template YAML file. It identifies the key elements of template inputs and output and the definition of modules. Along with the dependencies and variable linkage between modules for resource data passing. Definitions follow standard YAML syntax.
636e9f3a-feaf-4033-8603-687754dc7e51 TEST





 Example 9 

Lists the keys in the Key Protect instance and sort the keys based on their id and the date the key was created starting with the newest (the hyphen, '-', indicates sort by descending order).

 sort keys by id and descending creationDate
$ ibmcloud kp keys -b id,-creationDate

Retrieving keys...
OK
Key ID Key Name
ef2cc155-fe56-492c-845c-4d1f0688c7ba my-last-key
2f1cb135-fa16-40dc-815c-4d1f0ee8c7ba my-first-key







 Required parameters 



* -i, --instance-id

The IBM Cloud instance ID that identifies your Key Protect instance.

You can set an environment variable instead of specifying -i with the following command: $ export KP_INSTANCE_ID=<INSTANCE_ID>.







 Optional parameters 



* -b, --sort-by

Sort the keys based on the parameters. The default property for sorting results is "id." '-' before the parameter indicates sort by descending order. The supported sort parameters at this time are



* id
* state
* extractable
* imported
* creationDate
* lastUpdateDate
* lastRotateDate
* deletionDate
* expirationDate



* -c, --crn

Include the cloud resource name (CRN) in the output.
* -f, --key-filter

Filter the keys based on the parameters. The supported key filtering parameters are



* creationDate
* deletionDate
* expirationDate
* extractable
* lastUpdateDate
* lastRotateDate
* state



The supporting operators for dates are:



* gt (greater than)
* gte (greater than or equal to)
* lt (less than)
* lte (less than or equal to)
GET https://{bucket-name}.{endpoint} virtual host style





 Optional query parameters 



 Name Type Description 

 prefix String Constrains response to object names beginning with prefix. 
 delimiter String Groups objects between the prefix and the delimiter. 
 encoding-type String If unicode characters that are not supported by XML are used in an object name, this parameter can be set to url to properly encode the response. 
 max-keys String Restricts the number of objects to display in the response. Default and maximum is 1,000. 
 marker String Specifies the object from where the listing should begin, in UTF-8 binary order. 



Example request

This request lists the objects inside the "apiary" bucket.

GET /apiary HTTP/1.1
Content-Type: text/plain
Host: s3.us.cloud-object-storage.appdomain.cloud
Authorization: Bearer {token}

Example request

GET /apiary HTTP/1.1
Authorization: 'AWS4-HMAC-SHA256 Credential={access-key}/{date}/{region}/s3/aws4_request,SignedHeaders=host;x-amz-date;,Signature={signature}'
x-amz-date: {timestamp}
Content-Type: text/plain
Host: s3.us.cloud-object-storage.appdomain.cloud

Example response

HTTP/1.1 200 OK
Date: Wed, 24 Aug 2016 17:36:24 GMT
X-Clv-Request-Id: 9f39ff2e-55d1-461b-a6f1-2d0b75138861
Accept-Ranges: bytes
Server: Cleversafe/3.9.0.115
X-Clv-S3-Version: 2.5
x-amz-request-id: 9f39ff2e-55d1-461b-a6f1-2d0b75138861
Content-Type: application/xml
Content-Length: 909
maxLength 128 maxLength MUST be present. 
 pattern ^[-0-9A-Za-z]+$ pattern MUST be present. 









 Boolean 

The boolean type contains either a true or false value.



 Response format 

A boolean value MUST be returned as the JSON keyword true or the JSON keyword false.

[3]

In a response body, a boolean field MUST be required. If the property is inapplicable to certain states of the resource, this ternary capability MUST be represented explicitly with a enumeration containing values such as on, off, and inapplicable.



Schema guidance for booleans in responses

 Constraint Recommended value Description 

 type boolean type MUST be boolean. 







 Request formats 



 Request bodies 



* The JSON keyword true or the JSON keyword false MUST be considered a valid boolean.
* Any other value MUST be rejected with a 400 status code and appropriate error response model.



In a request body, a boolean field MAY be optional. An optional boolean field MUST have either an explicit default value or an explanation of the strategy used to compute a value in the property schema description.





 Query parameters 



* The strings true and false MUST be case-insensitively matched as valid booleans.
* Any other string MUST be considered invalid and SHOULD be rejected with a 400 status code and appropriate error response model.



The character set of a boolean query parameter value within a request MUST be verified prior to case normalization

[4].

Despite all values being encoded as strings within the request URL, a boolean query parameter MUST be defined with a boolean schema. OpenAPI does not itself specify valid encoding for query parameters with boolean schemas, which makes the preceding guidance crucial.



Schema guidance for booleans in requests

 Constraint Recommended value Description 

 type boolean type MUST be boolean. 











 Integer 

The integer type provides for whole number values between -2^53 + 1 (-9,007,199,254,740,991) and 2^53 - 1 (9,007,199,254,740,991)

[5].



 Response format
Setting up an IPsec VPN connection 



 What is IPsec VPN? 

IPsec is a suite of protocols that are designed to authenticate and encrypt all IP traffic between two locations. It allows trusted data to pass through networks, which otherwise would be considered insecure. IPsec tunnel endpoints can be located anywhere and still provide access to your entire private network, or the networks you specify. IPsec tunnels are incompatible if you are using a zone, or cloud service endpoints.

IBM Cloud VPN access allows users to manage all servers remotely and securely over the IBM Cloud Private network. A VPN connection from your location to the private network gives you the capability for out-of-band management and server rescue through an encrypted VPN tunnel. With VPN access, you can:



* Establish a VPN connection to the private network through SSL or IPsec.
* Access your server by using its private 10.x.x.x IP address through SSH or RDP.
* Connect to your server’s IPMI IP address for additional server management or rescue needs.



We provide the IPsec service to customers for management of their environments. It is not recommended for production workloads.



 Negotiation parameters 

You need to know the following information for the remote side of the IPsec VPN:



* Static IP address for VPN endpoint
* Preshared key (Password)
* Encryption algorithm (DES, 3DES, AES128, AES192, AES256)
* Authentication (MD5, SHA1, SHA256, for phase 1&2)
* Diffie-Hellman Group (for phase 1&2)
* Is Perfect Forward Secrecy (PFS) used?
* Key life time (for phase 1 & 2) - Note: Our system measures this value in seconds!



After you have this information available, you can configure the basic negotiation parameters of the VPN connection.





 Protected networks 

In the VPN connection properties, you must define the networks on the remote end of the tunnel and the local networks for the tunnel.
See the [VPC API Reference](https://cloud.ibm.com/apidocs/vpc-on-classic) to verify that you are providing the correct parameters in the request body.





 volume_update_invalid_request 

Message: The volume update request is not valid.

The update request body property that you specified is not valid. See the [VPC API Reference](https://cloud.ibm.com/apidocs/vpc-on-classic) for information and correct API request syntax.





 vpc_not_empty 

Message: The VPC cannot be deleted because it is not empty.

All resources in the VPC must be deleted before the VPC can be deleted. A VPC contains instances, subnets, public gateways, load balancers and VPN gateways, and some of these resources contain resources as well. Refer to [How to Delete a VPC](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-deleting) documentation for details.

If this problem persists, [contact support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support).





 vpc_resource_separation 

Message: The resources are in different VPCs.

The resources must be in the same VPC. For example, if you are attempting to attach a public gateway to a subnet, the public gateway must be in the same VPC as the subnet.

To determine which VPC contains the public gateway, run the GET /public_gateways/{id} command and look at the "vpc" value. The equivalent CLI command is ibmcloud is public-gateway <id>.





 vpn_connection_cidr_duplicated 

Message: The <cidr_type> CIDR blocks have duplicated CIDR blocks <cidr_blocks>.

Duplicate CIDR blocks have been provided when creating the connection. Ensure that the CIDR blocks are unique.
* [Delete a file share](https://cloud.ibm.com/apidocs/vpc-betadelete-share)
* [Delete a share mount target](https://cloud.ibm.com/apidocs/vpc-betadelete-share-mount-target)





 Action needed 

Before you specify version query parameter of 2023-05-30 or later, follow these actions to avoid regressions in client functionality.



 Client migration 

Before you migrate a client to API version 2023-05-30 or later, review your code for use of the targets property. Change all instances of targets to mount_targets in the manner appropriate for your programming language. Changes are required in all relevant request paths, and request and response JSON field name formats. For more information, see the [Beta API change log](https://cloud.ibm.com/docs/vpc?topic=vpc-api-change-log-betaversion-2023-05-30-beta).







 Examples 

These examples compare differences between before and after the 2023-05-30 versioned change. All requests that use a version query parameter of 2023-05-30 or later must use /shares/{share_id}/mount_targets (instead of /shares/{share_id}/targets) in the request URL.



 Listing a file share and mount targets 

The following examples compare how to make a request to list a file share and mount targets before and after the 2023-05-30 versioned change. The path of the API request is different before and after the change.

This request lists a file share and mount targets, specifying API version 2023-05-29 or earlier. The path of the API request includes /targets.

curl -X GET "$vpc_api_endpoint/v1/shares/{share_id}/targets?version=2023-05-29&generation=2&maturity=beta" -H "Authorization: Bearer $iam_token" -H 'Content-Type: application/json'

This request lists a file share and mount targets, specifying API version 2023-05-30 or later.
narrowband_recognize The Speech to Text service configuration to use for narrowband codecs (such as PCMU and PCMA, which are sampled at 8 kHz). The parameters defined by this object are used when connecting to the Speech to Text service for speech recognition requests. For more information about these parameters, see the [Speech to Text API documentation](https://cloud.ibm.com/apidocs/speech-to-textWSRecognizeMethod). no Current Speech to Text configuration 
 broadband_recognize The Speech to Text service configuration to use for broadband codecs (such as G722, which is sampled at 8 kHz). The parameters defined by this object are used when connecting to the Speech to Text service for speech recognition requests. For more information about these parameters, see the [Speech to Text API documentation](https://cloud.ibm.com/apidocs/speech-to-textWSRecognizeMethod). no Current Speech to Text configuration 
 band_preference Specifies which audio band (narrowband or broadband) is preferred when negotiating audio codecs for the session. Set to broadband to use broadband audio when possible. no narrowband 
 update_strategy Specifies the update strategy to use when setting the speech configuration. Possible values include:<br><br><br><br> * replace: Replaces the configuration for the rest of the session. Any root-level fields in the new configuration completely overwrite the previous configuration.<br> * replace_once: Replaces the configuration only for the next turn of the conversation. Subsequently, the previous configuration is used.<br> * merge: Merges the new configuration with the existing configuration for the rest of the session. Only changed parameters are overwritten; any other configuration parameters are unchanged.<br> * merge_once: Merges the new configuration with the existing configuration only for the next turn of the conversation. Subsequently, the previous configuration is used.<br><br><br> no replace 



The parameters that you can set for narrowband_recognize and broadband_recognize reflect the parameters that are made available by the Speech to Text WebSocket interface.
The following command again uses the POST /v1/synthesize method to synthesize the same US English input to audio. But this request uses the voice en-US_AllisonV3Voice and explicitly requests audio in the default Ogg format.



1. Issue the following command to synthesize the string "hello world" but with a different voice. The request produces an Ogg file that is named hello_world.ogg.

IBM Cloud



* Replace {apikey} and {url} with your API key and URL.



curl -X POST -u "apikey:{apikey}" --header "Content-Type: application/json" --data "{"text":"hello world"}" --output hello_world.ogg "{url}/v1/synthesize?voice=en-US_AllisonV3Voice"

IBM Cloud Pak for Data



* Replace {token} and {url} with the access token and URL for your service instance.



curl -X POST --header "Authorization: Bearer {token}" --header "Content-Type: application/json" --header "Accept: audio/wav" --data "{"text":"hello world"}" --output hello_world.wav "{url}/v1/synthesize?voice=en-US_AllisonV3Voice"







 Step 3: Synthesize text in Spanish 

The following command uses the GET /v1/synthesize method to synthesize Spanish input to an audio file. The GET method includes three query parameters: accept to specify the audio format, text to specify the input text for the audio, and voice to specify a Spanish voice. Because accept and text are passed as query parameters, the request is URL-encoded.



1. Issue the following command to synthesize the string "hola mundo" and produce a WAV file that is named hola_mundo.wav.

IBM Cloud



* Replace {apikey} and {url} with your API key and URL.
* Final results are identified with the field "final": true. The service makes no further updates to final results.



How you request interim results depends on the type of model that you are using:



* For a previous-generation model, set the interim_results parameter to true in the JSON start message. Interim results are available for all previous-generation models.
* For a next-generation model, set the interim_results and low_latency parameters to true in the JSON start message. Interim results are available only for next-generation models that support low latency, and only if both interim results and low latency are enabled. For more information, see [Requesting interim results and low latency](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-interiminterim-low-latency).



To disable interim results for any model, omit the interim_results parameter or set it to false. Disable interim results if you are doing offline or batch transcription.



 Interim results example 

The following abbreviated WebSocket example requests interim results. The service sends multiple response objects. It sets the final attribute to true only for the final results. The request implicitly uses the default previous-generation en-US_BroadbandModel.

var access_token = {access_token};
var wsURI = '{ws_url}/v1/recognize'
+ '?access_token=' + access_token;
var websocket = new WebSocket(wsURI);

websocket.onopen = function(evt) { onOpen(evt) };
function onOpen(evt) {
var message = {
action: 'start',
content-type: 'audio/l16;rate=22050',
interim_results: true
};
websocket.send(JSON.stringify(message));
websocket.send(blob);
}

websocket.onmessage = function(evt) { onMessage(evt) };