vania-janet/multiturn-rag-retrieval-data huggingface dataset:
unauthenticated error code can accompany a 401 HTTP status code.

Example message: The provided token is invalid or expired.





 unauthorized 

Used for headers, parameters, paths, or properties (identified by the target) that are syntactically valid but refer to a resource that you are not authorized to operate on in the requested manner.

unauthorized error code can accompany a 403 HTTP status code.

Example message: The metadata service is not enabled on the provided instance.





 unknown_field 

Used when an unknown query parameter or property is provided.

unknown_field error code can accompany a 400 HTTP status code.

Example message: Unknown property xyzzy was specified in the request body.
Typically your onsite networking team will specify the configuration to match agreed corporate standards and provide you with the necessary IP address of the data center VPN gateway, and the subnet address ranges that can be accessed.

Before commencing setup of the VPN, the IP addresses of the VPN gateways and IP network subnet ranges must be determined and available for the data center VPN configuration and for the secure private network enclosure in the IBM Cloud. These are illustrated in the following figure, where the APP zone in the secure enclosure will be connected via the IPSec tunnel to systems in the ‘DC IP Subnet’ in the client data center.

Zoom

![IPSec tunnel](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution36-configuring-IPSEC-VPN/vpn-addresses.png)

IPSec tunnel

The following parameters must be agreed and documented between the IBM Cloud user configuring the VPN and the networking team for the client data center. In this example the Remote and Local tunnel IP addresses are set to 192.168.10.1 and 192.168.10.2. Any arbitrary subnet may be used with agreement of the on-site networking team.



List of parameters to review to configure the VPN

 Item Description 

 Name given to the IKE group for the connection. 
 Agreed IKE encryption standard to be used between IBM Cloud and the client data center, typically aes256. 
 Agreed IKE hash between IBM Cloud and client data center, typically sha1. 
 IKE lifetime from client data center, typically 3600. 
 Name given to ESP group for the connection. 
 Agreed ESP encryption standard between IBM Cloud and client data center, typically aes256. 
 Agreed ESP hash between IBM Cloud and client data center, typically sha1. 
 ESP lifetime from client data center, typically 1800. 
 Internet facing public IP address of the VPN gateway at the client data centre. 
 Public IP address of the VRA.
This process is used to set the resource consumption limits of individual vDisks in a Virtual Servers even when SIOC is not enabled. These settings are specific to the individual guest, and not the host, although they are used by SIOC.







 Configuring ESXi host side settings 

Other settings are required for configuring ESXi hosts for NFS storage. This table shows what each setting needs to be.



Table 2 - Host side settings.

 Parameter Set to ... 

 Net.TcpipHeapSize 32 for vSphere 5.0 and later versions 
 Net.TcpipHeapMax <br><br> * 1536 for vSphere 6.0 and later versions,<br> * 512 for vSphere 5.5,<br> * 128 for vSphere 5.0 and 5.1<br><br><br> 
 NFS.MaxVolumes 256 for vSphere 5.0 and later versions 
 NFS41.MaxVolumes 256 for vSphere 6.0 and later versions 
 NFS.HeartbeatMaxFailures 10 for all NFS configurations 
 NFS.HeartbeatFrequency 12 for all NFS configurations 
 NFS.HeartbeatTimeout 5 for all NFS configurations 
 NFS.MaxQueueDepth 64 for vSphere 5.0 and later versions 





 Updating advanced configuration parameters 

The following examples use the ESXi CLI to set the advanced configuration parameters, and then, check them. The esxcfg-advcfg tool that is used in the examples can be found in the /usr/sbin directory on the ESXi hosts.



* Setting the advanced configuration parameters from the ESXi CLI.



esxcfg-advcfg -s 32 /Net/TcpipHeapSize
esxcfg-advcfg -s 128 /Net/TcpipHeapMax(For vSphere 5.0/5.1)
esxcfg-advcfg -s 512 /Net/TcpipHeapMax(For vSphere 5.5 and higher)
Credentials are service-specific and vary based on how each service defines the credentials they need to generate. A service credential might contain a user name, password, host name, port, and a URL.

However, the contents of each credential is unique to the service that generates it. Some services might generate extra data that requires parameters to be passed in. For example, a service might require you to input a language parameter to set the default language that is returned in the service key that is generated.

Complete the following steps to add a Cloud Foundry credential:



1. From the service details page, select the Credentials tab, and click New Credential.
2. From the Add New Credential dialog, provide a Name.
3. Optionally, you can provide more parameters as a valid JSON object that contains service-specific configuration parameters, provided either inline or in a file.

Most services don't require extra parameters, and for services that do, each service defines its own unique list of parameters. For a list of supported configuration parameters, see the documentation for the particular service offering.
4. Click Add to generate the new service credential.







 Adding a credential when binding a Cloud Foundry service by using the API 

Service credential bindings are used to make the details of the connection to a service instance available to an app or a developer. Service credential bindings can be of type app or key.

A service credential binding is of type app when it is a binding between a [service instance](http://v3-apidocs.cloudfoundry.org/version/3.99.0/index.htmlservice-instances){}: external} and an [application](http://v3-apidocs.cloudfoundry.org/version/3.99.0/index.htmlapps). Not all services support this binding, as some services deliver value to users directly without integration with an application.
: Previously, a replication job that failed for some reason, which resulted in an update to the replication document, was followed by a fresh attempt to start a new replication. Under some circumstances, this behavior might continue indefinitely: many duplicates of the same error message. A fix was introduced so that the replication document is not updated unless the reason for the error changes.







 February 2017 



 13 February 2017 

The following changes were made in build 5834:

Document id length
: The maximum length of a document id is now 7168 characters (7k).







 November 2016 



 25 November 2016 

The following changes were made in build 5728:

Malformed user documents
: IBM Cloudant is more tolerant of malformed user documents that are stored within the _users database.

Structure for user documents
: User documents must be structured and populated to comply with [Apache CouchDB requirements](https://docs.couchdb.org/en/stable/intro/security.html?highlight=securityusers-documents).







 October 2016 



 11 October 2016 

The following changes were made in build 5638:

New! Parameters
: Introduces new stable and update query parameters for views.

Replicator retries
: Replicator no longer retries forever if it cannot write checkpoints to the source database.







 June 2016 



 14 June 2016 

The following changes were made in build 5421:

View-based filters
: Changes feeds support view-based filters.

_docs_ids filter
: Changes feeds support the _doc_ids filter.

POST requests
: POST requests are supported for _changes.

attachments=true parameter support
: Both _all_docs and _changes support the attachments=true parameter.

CouchDB 1.6 _users database support
: Support for the CouchDB 1.6 _users database features, including server-side hashing of passwords when documents are created in the _users database.

/_bulk_get endpoint
: /_bulk_get endpoint to reduce the number of requests that are used in replication to mobile clients.

Design document metadata
: Design document metadata contains an update pending field.

Eliminate error
The structure and format of the service's response is the same regardless of whether you use a previous- or next-generation model.

{
"result_index": 0,
"results": [
{
"alternatives":
{
"confidence": 0.99,
"transcript": "one two "
}
],
"final": true
},
{
"alternatives":
{
"confidence": 0.99,
"transcript": "three four "
}
],
"final": true
}
]
}
Show more





 Example request with interim results 

The client requests interim results as follows:



* For previous-generation models, by setting the interim_results parameter to true.
* For next-generation models, by setting both the interim_results and low_latency parameters to true. To receive interim results with a next-generation model, the model must support low latency and both the interim_results and low_latency parameters must be set to true.



* For more information about which next-generation models support low latency, see [Supported next-generation models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-models-ngmodels-ng-supported).
* For more information about the interaction of the interim_results and low_latency parameters with next-generation models, including examples that demonstrate the different combinations of parameters, see [Requesting interim results and low latency](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-interiminterim-low-latency).





The client receives multiple JSON objects in response. The service returns separate response objects for each interim result and for each each final result that is generated by the audio. The service sends at least one interim result for each final result.

The service sends responses as soon as they are available. It does not wait for a stop message to send its results, though the stop message is still required to signal the end of transmission for the request.
Connecting to a FortiGate peer 

You can use IBM Cloud VPN for VPC to securely connect your VPC to an on-prem network through a VPN tunnel. This topic provides guidance about how to configure your FortiGate VPN gateway to connect to VPN for VPC.

These instructions are based on FortiGate 300C, Firmware Version v5.2.13, build762 (GA).

Read [VPN gateway limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-limitations) before you continue to connect to your on-premises peer.



 Connecting an IBM policy-based VPN to a FortiGate peer 

Select VPN > IPsec Tunnels and create a new custom tunnel, or edit an existing tunnel.

When a FortiGate VPN receives a connection request from VPN for VPC, FortiGate uses IPsec Phase 1 parameters to establish a secure connection and authenticate VPN for VPC. Then, if the security policy permits the connection, the FortiGate VPN establishes the tunnel using IPsec Phase 2 parameters and applies the IPsec security policy. Key management, authentication, and security services are negotiated dynamically through the IKE protocol.

To support these functions, the following general configuration steps must be performed for the FortiGate VPN:



* Define the Phase 1 parameters that the FortiGate VPN requires to authenticate VPN for VPC and establish a secure connection.
* Define the Phase 2 parameters that the FortiGate VPN requires to create a VPN tunnel with VPN for VPC.
* Create security policies to control the permitted services and permitted direction of traffic between the IP source and destination addresses.



An example configuration is as follows:



1. Choose IKEv2 in authentication.
2. Enable DH-group 19 in the Phase 1 proposal.
3. Set lifetime = 36000 in the Phase 1 proposal.
4. Disable PFS in the Phase 2 proposal.
5. Set lifetime = 10800 in the Phase 2 proposal.
6. Input your subnet's information in Phase 2.
7. The remaining parameters keep their default values.
Not seeing the full list of keys? You might need to use limit and offset or check with your administrator to ensure you're assigned the correct level access to keys in your instance. To learn more, see [Unable to view or list keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-troubleshoot-unable-to-list-keys-api).







 Retrieving a subset of keys 

By specifying the limit and offset parameters at query time, you can retrieve a subset of your keys, starting with the offset value that you specify.

For example, you might have 3000 total keys that are stored in your Hyper Protect Crypto Services service instance, but you want to retrieve keys 200 - 300 when you make a GET /keys request.

You can use the following example request to retrieve a different set of keys.

curl -X GET 
'https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/keys?offset=<offset>&limit=<limit>' 
-H 'accept: application/vnd.ibm.collection+json' 
-H 'authorization: Bearer <IAM_token>' 
-H 'bluemix-instance: <instance_ID>'

Replace the limit and offset variables in your request according to the following table.



Table 2. Describes the limit and offset variables

 Variable Description 

 offset The number of keys to skip. For example, if you have 50 keys in your instance, and you want to list keys 26 - 50, use ../keys?offset=25. You can also pair offset with limit to page through your available resources. 
 limit The number of keys to retrieve. For example, if you have 100 keys in your instance, and you want to list only 10 keys, use ../keys?limit=10. The maximum value for limit is 5000. 



For usage notes, check out the following examples for setting your limit and offset query parameters.



Table 3. Provides usage notes for the limit and offset query parameters

 URL Description 

 .../keys Lists all of your available resources, up to the first 2000 keys.
ibmcloud tg connection-create-gre $gateway --network-type unbound_gre_tunnel --name unbound-gre-connection --base-network-type classic --zone us-south-2 --local-gateway-ip 192.168.100.1 --local-tunnel-ip 192.168.101.1 --remote-gateway-ip 10.242.63.12 --remote-tunnel-ip 192.168.101.2







 Creating an unbound Generic Routing Encapsulation (GRE) tunnel connection with the API 

To create an unbound Generic Routing Encapsulation (GRE) tunnel connection with the API, perform the following actions:



 Request 

To request a creation of an Unbound Generic Routing Encapsulation (GRE) tunnel connection, set the following parameters:



Table 1. Path parameters for creating a GRE

 Path parameters Details 

 transit_gateway_id <br>Required <br>string The transit gateway identifier 





Table 2. Query parameters for creating a GRE

 Query parameters Details 

 version <br>Required <br>string Requests the version of the API as of a date in the format YYYY-MM-DD. Any date up to the current date may be provided. Specify the current date to request the latest version. <br>Possible values: Value must match the regular expression: ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ 
 Request Body <br>Required <br>TransitGatewayConnectionTemplate The connection template. 
 network_type <br>Required <br>string Defines what type of network is connected using this connection. <br>For access to unbound_gre_tunnel connections, contact IBM support. <br>Allowable value:[unbound_gre_tunnel] <br>Example:unbound_gre_tunnel 
 base_network_type <br>Required <br>string Defines what type of network the GRE tunnel is targeting. This field is required for and only applicable to type unbound_gre_tunnel connections.
ibmcloud fn package get <namespace_ID>cloud-object-storage parameters

You still need to pass the bucket and endpoint values during action invocation. Or, you can bind these parameters to the package or an action. To do this, see [Setting default parameters for a package or action](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_obstoragepkg_obstorage_param_bind).







 Setting default parameters for a package or action 

Rather than manually passing your bucket and endpoint with each action invocation, you can use the [package update](https://cloud.ibm.com/docs/openwhisk?topic=cloud-functions-cli-plugin-functions-clicli_pkg_bind) command to bind your bucket and endpoint parameters to a specific action or to the cloud-object-storage package. You can find your <bucket_endpoint> value on the Endpoint tab in the COS console.

For a list of endpoints, see [Endpoints and storage locations](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpointsendpoints).

To set a default bucket-name and bucket-endpoint value, copy one of the following commands. Replace <bucket-name> with the name of your bucket and replace <bucket_endpoint> with the endpoint of your bucket.

When you update parameters for a package, action, or trigger you must specify all previously created parameters. Otherwise, the previously created parameters are removed. Any services that were bound to the package are also removed, so after you update other parameters you must [bind services](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-services) to your package again.



 Updating parameters for all actions in a package 

ibmcloud fn package update cloud-object-storage
--param bucket <bucket-name>
--param endpoint <bucket-endpoint>





 Updating parameters to a specific action
"format": "%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}"
}
},
"metrics": {
"provider": "disabled",
"statsd": {
"network": "udp",
"address": "127.0.0.1:8125",
"writeInterval": "10s",
"prefix": null
}
}
}
Show more





 Providing your own customizations when you create a peer 

After you click Create a peer on the nodes tab and step through the peer configuration panels, you can click Edit configuration on the Summary panel to view and edit the JSON. Note that if you do not select any advanced options in the console, then the generated JSON is empty, but you can still insert your own customizations.

Alternatively, if you do check any of the advanced options when you configure the peer, those settings are included in the JSON on the Summary panel and can be additionally customized with other fields as needed. Any edits that you make will override what was specified in the console. For example, if you selected to use a LevelDB as the state database, but then overrode the setting to use CouchDB as the state database in the JSON, then the CouchDB database settings would be used when the peer is deployed. The override settings that are visible in the JSON on the Summary page are what is used when the peer is deployed.

You don't need to include the entire set of available parameters in the JSON, only the advanced deployment options that you selected in the console along with the parameters that you want to override. For example, if you want to deploy a peer and override the chaincode startup timeout and specify a different port for the statsd address, you would paste in the following JSON:

{
"peer": {
"chaincode": {
"startuptimeout": "600s"
}
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.



curl -X GET -u "apikey:{apikey}" --output hola_mundo.wav "{url}/v1/synthesize?accept=audio%2Fwav&text=hola%20mundo&voice=es-ES_EnriqueV3Voice"

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}" --output hola_mundo.wav "{url}/v1/synthesize?accept=audio%2Fwav&text=hola%20mundo&voice=es-ES_EnriqueV3Voice"







 Next steps 



* To try an example application that accepts text and generates speech with different voices, see the [Text to Speech demo](https://www.ibm.com/demos/live/tts-demo/self-service/home).
* For more information about the service's interfaces and features, see [Service features](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-service-features).
* For more information about all methods of the service's interfaces, see the [API & SDK reference](https://cloud.ibm.com/apidocs/text-to-speech).
For example, if there are five admins in a channel, choose 3 out of 5.







 Advanced options 

By clicking the box under advanced options, users can access parameters that users should take caution in updating. Note that if you are attempting to change any parameter that requires the signature of ordering service admins (for example, the Block cutting parameters or ordering service consenters) and are one of the ordering service admins on this channel, you will see a field for the ordering service organization. Select the MSP of the relevant ordering service organization from the drop-down list (if you are not an ordering service admin, the MSP will have to be exported to you). If you are not an admin of the ordering service organization, you can still make a request to change one of the block cutting parameters, but the request must be signed by an ordering service admin.

If the signature of an ordering service org admin is required, you will not see a pending tile for the channel in your console until the ordering service org has signed the request. When you see the tile, you can join your peer to it.



* Capabilities. If you're unfamiliar with capabilities, check out [Channel capabilities](https://hyperledger-fabric.readthedocs.io/en/release-2.2/capabilities_concept.html) in the Fabric documentation. Note that there is a strict relationship between the Fabric version of your nodes and the levels of certain capabilities that must be followed to ensure that nodes do not crash and desired functionalities are available. Currently, only application and orderer capabilities can be set during channel creation. For information about channel capabilities (which are a level of capabilities that span both ordering nodes and peers and do not refer to "capabilities on the channel") and how to change them, check out the [Capabilities](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-governibp-console-govern-capabilities) section below.
* Lifecycle endorsement policy. (Only available on networks using v2.0 application capabilities) This defines how many channel members must approve a smart contract definition before the smart contract can be used on the channel.
You can save a purge group to be a favorite (permanent) group or not. For more information, see [With multiple file purges, what's the difference between a favorite group and an unfavorite group?](https://cloud.ibm.com/docs/CDN?topic=CDN-faqswhat-different-two-type-favorite-group).

There's also a rate limit to the purge actions. For more information, see [What's the rate limit for a multiple file purge?](https://cloud.ibm.com/docs/CDN?topic=CDN-limits-and-maximum-valuespurge-rate-limit).

For an example of how to create a purge group, see [Example code for creating a purge group](https://cloud.ibm.com/docs/CDN?topic=CDN-code-examples-using-the-cdn-apicreate-group-example).



* Parameters:



* uniqueId - The unique ID of the CDN mapping for which the purge group was created.
* name - Purge group name. The favorite group name must be unique. Unfavorite groups do not have this limitation.
* paths - A collection of purge paths.
* option - The following options are available to create a purge group:



* 1 - Create the purge group as an unfavorite group, and run a purge action. Default
* 2 - Create the purge group as a favorite group, and do not run a purge action.
* 3 - Create the purge group as a favorite group, and run a purge action.





* Return - SoftLayer_Container_Network_CdnMarketplace_Configuration_Cache_PurgeGroup.

[Purge Group container](https://cloud.ibm.com/docs/CDN?topic=CDN-purge-group-container)



--------------------





 getPurgeGroupByGroupId 

Gets a purge group.



* Parameters:



* uniqueId - The unique ID of the mapping.