vania-janet/multiturn-rag-retrieval-data huggingface dataset:
curl -X GET -u "apikey:{apikey}" "{url}/v1/customizations/82f4809a-bf63-89a6-52ca-22731fe467ba/prompts/goodbye"

IBM Cloud Pak for Data

curl -X GET --header "Authorization: Bearer {token}" "{url}/v1/customizations/82f4809a-bf63-89a6-52ca-22731fe467ba/prompts/goodbye"

While the service is evaluating the prompt, the status is processing. When the status becomes available, as shown in the following response, the prompt is ready to be used in a synthesis request. If the status is failed, a problem prevented creation of the prompt; the service includes an error message to describe the reason for the failure.

{
"prompt": "Thank you and good-bye!",
"prompt_id": "goodbye",
"status": "available",
"speaker_id": "823068b2-ed4e-11ea-b6e0-7b6456aa95cc"
}

Only prompts that are in the available state can be used for speech synthesis. No prompt can be used for speech synthesis if it is in the processing or failed state. For more information about checking the status of a prompt, see [Listing custom prompts](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-tbe-custom-promptstbe-custom-prompts-list).







 Evaluate the custom prompt 

When you create a prompt, the text of the prompt must reasonably match the spoken audio. The service does its best to align the specified text with the audio, and it can often compensate for mismatches between the two. If the differences between the text and the audio are too pronounced, however, the service cannot create the prompt. The longer the prompt, the greater the chance for misalignment between its text and audio. Multiple shorter prompts are therefore preferable to a single long prompt.
400 Bad Request 
 MaxPostPreDataLengthExceededError Your POST request fields preceding the upload file were too large. 400 Bad Request 
 MetadataTooLarge Your metadata headers exceed the maximum allowed metadata size. 400 Bad Request 
 MethodNotAllowed The specified method is not allowed against this resource. 405 Method Not Allowed 
 MissingContentLength You must provide the Content-Length HTTP header. 411 Length Required 
 MissingRequestBodyError This happens when the user sends an empty xml document as a request. The error message is, "Request body is empty." 400 Bad Request 
 NoSuchBucket The specified bucket does not exist. 404 Not Found 
 NoSuchKey The specified key does not exist. 404 Not Found 
 NoSuchUpload The specified multipart upload does not exist. The upload ID might be invalid, or the multipart upload might have been aborted or completed. 404 Not Found 
 NotImplemented A header that you provided implies functionality that is not implemented. 501 Not Implemented 
 OperationAborted A conflicting conditional operation is currently in progress against this resource. Try again. 409 Conflict 
 PreconditionFailed At least one of the preconditions you specified did not hold. 412 Precondition Failed 
 Redirect Temporary redirect. 307 Moved Temporarily 
 RequestIsNotMultiPartContent Bucket POST must be of the enclosure-type multipart/form-data. 400 Bad Request 
 RequestTimeout Your socket connection to the server was not read from or written to within the timeout period. 400 Bad Request 
 RequestTimeTooSkewed The difference between the request time and the server's time is too large. 403 Forbidden 
 ServiceUnavailable Reduce your request rate. 503 Service Unavailable 
 SlowDown Reduce your request rate. 503 Slow Down 
 TemporaryRedirect You are being redirected to the bucket while DNS updates. 307 Moved Temporarily 
 TooManyBuckets You have attempted to create more buckets than allowed. 400 Bad Request 
 UnexpectedContent This request does not support content. 400 Bad Request
For more information, see [the partitioned field](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-querysection1-the-partitioned-field). 





 The partitioned field 

This field sets whether the created index is a partitioned or global index.



Table 2. Partitioned field values

 Value Description Notes 

 true Create the index as partitioned. Can be used only in a partitioned database. 
 false Create the index as global. Can be used in any database. 



The default follows the partitioned setting for the database:



Table 3. Default partitioned value

 Is the database partitioned? Default partitioned value Allowed values 

 Yes true true, false 
 No false false 



It's important to reiterate that the default partitioned value is true for indexes that are created in a partitioned database. This default value means that the index cannot be used to satisfy global queries.



Table 4. Return codes

 Code Description 

 200 Index was created successfully or existed in the database. 
 400 Bad request - the request body doesn't have the specified format. 









 Creating a type=text index 

When you create a single text index, it's a good practice to use the default values, but some useful index attributes can be modified.

A text index can be partitioned or global; this option is set by using the partitioned field.

For Full Text Indexes (FTIs), type must be set to text.

The name and ddoc attributes are for grouping indexes into design documents. Use the attributes to refer to index groups by using a custom string value. If no values are supplied for these fields, they're automatically populated with a hash value.

If you create multiple text indexes in a database, with the same ddoc value, you need to know at least the ddoc value and the name value. Creating multiple indexes with the same ddoc value places them into the same design document. Generally, you must put each text index into its own design document.
The automation deploys an example NSX-T overlay topology with a Tier 1 (T1) Gateway and a few example segments attached both to the T1 and T0 Gateways. You might customize the topology based on your needs.
4. IBM Cloud Services can be reached through IBM Cloud private network by using Cloud Services Endpoints when it uses IBM Cloud private network addresses.
5. When you use BYOIP on NSX-T overlay networks, you must use SNAT at T0 or T1. If you use SNAT at T1, you can advertise the NAT IP addresses from T1 to T0, where proxy ARP is used.
6. You can create DNAT rules on T0 Gateway to access your workloads from IBM Cloud private networks.
7. You can use IP addresses from IBM Cloud private portable subnet that is deployed for NSX-T Edge Uplinks for the NAT.







 Ingress private connectivity 

Private ingress connectivity to NSX-T overlay is enabled through NAT or though using overlay tunnels. You can use IP addresses from the private portable subnet that is provisioned for T0 private uplinks for these use cases.

Zoom

![Private ingress access to IBM Cloud NSX-T overlay](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-nsx-t-private-access-ingress.svg)

Figure 2. Private ingress access to IBM Cloud NSX-T overlay

The following steps summarize this architecture pattern deployment.



1. The automation deploys an NSX-T T0 Gateway in the NSX-T workload edge cluster. The T0 gateway provides connectivity to the IBM Cloud private network.
2. The automation deploys an example NSX-T overlay topology with a T1 Gateway and a few example segments attached both to the T1 and T0 Gateways. You can customize the topology based on your needs.
3.
In the Region 2 console, import the os4-Region3, and os5-Region3 files by repeating the same steps that you used in the Region 1 console.
3. In the Region 3 console, import the os3-Region2 file by repeating the same steps.



The ordering service is now synchronized in each console across each region and can be used to create application channels between consortium members.

To summarize, anytime a new ordering node is added to the ordering service in a console, it needs to be exported and then imported into the ordering service in the consoles in the other regions. When you subsequently create an application channel based on this ordering service, under the advanced options, you can select which ordering nodes to include in the consenter set. Therefore, it is important that your console is up to date with all of the available ordering nodes before creating the channel in order to include them to the channel consenter set.

The following screen capture shows what the ordering service looks like on the console in Region 1. Notice the Imported label on the three tiles from the other clusters. The ordering service should be identical in Region 2 and Region 3 except for the Imported labels, since they will vary by region.

Zoom

![Multiregion ordering service](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/multiregion-os.png)

Figure 5. Multiregion ordering service





 Next steps 



* Create application channels

The multiregion ordering service is now configured for HA across regions and is ready for peer organizations to create application channels. If the peers do not reside in any of the consoles that are used in this tutorial, you need to export our five-node ordering service and import it along with the orderer organization MSP into the console where the peer resides. This allows the peer organization admin to create application channels that are based on the ordering service.
"message": "Incorrect Location Input.",
"statuscode": 400
}

The Schematics global endpoint is defaulted to us environment. Therefore, you need to use [regional endpoints](https://cloud.ibm.com/apidocs/schematics/schematicsapi-endpoints) to point your location to a eu-de region.
* How can I view workspace resources?

Use the [state list](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-cli-referencestate-list) CLI command to view the same resources as in IBM Cloud Schematics UI.
* How do I fix the CreateworkspaceWithContext failed Bad request error?

Error

CreateWorkspaceWithContext failed Bad request. Check that the information you entered in the payload is complete and formatted correctly in JSON.

The Schematics public or private endpoint global URL by default points to us region. As a workaround you can set the [environment variable key](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-provider-referenceconfig-provider) before the Terraform commands.


export IBMCLOUD_SCHEMATICS_API_ENDPOINT="https://eu-de.schematics.cloud.ibm.com"


You can also add the endpoints to a JSON file to categorize the endpoints service as public or private.

Sample provider declaration

{
"IBMCLOUD_SCHEMATICS_API_ENDPOINT":{
"public":{
"eu-de":"https://eu-de.schematics.cloud.ibm.com"
}
}
}

Example Provider Block

provider "ibm" {

endpoints_file_path= "endpoints.json"
}
* Are sensitive values in the state file encrypted?

Schematics encrypts the Terraform state file when stored and also in transit using TLS.
This service is built on FIPS 140-2 Level 4 certified HSMs and supports the Keep Your Own Key (KYOK) capability. You can take the ownership to ensure your full control of the entire key hierarchy with no access even from IBM Cloud administrators. Hyper Protect Crypto Services also supports industry standards such as Public-Key Cryptography Standards #11 (PKCS #11) for cryptographic operations like digital signing and Secure Sockets Layer (SSL) offloading.





 How is Keep Your Own Key different from Bring Your Own Key? 

Bring Your Own Key (BYOK) is a way for you to use your own keys to encrypt data. The key management services that provide BYOK are typically multi-tenant services. With these services, you can import your encryption keys from the on-premises hardware security modules (HSM) and then manage the keys.

With Keep Your Own Key (KYOK), IBM brings industry-leading level of control that you can exercise on your own encryption keys. In addition to the BYOK capabilities, KYOK provides technical assurance that IBM cannot access the customer keys. With KYOK, you have exclusive control of the entire key hierarchy, which includes the master key.

The following table details the differences between KYOK and BYOK.



Table 1. Comparing BYOK with KYOK

 Cloud key management capabilities BYOK KYOK 

 Managing encryption key lifecycle Yes Yes 
 Integrating with other cloud services Yes Yes 
 Bringing your own keys from on-premises HSMs Yes Yes 
 Operational assurance - Cloud service providers cannot access keys. Yes Yes 
 Technical assurance - IBM cannot access the keys. No Yes 
 Single tenant, dedicated key management service. No Yes 
 Exclusive control of your master key. No Yes 
 Highest level security - FIPS 140-2 Level 4 HSM. No Yes 
 Managing your master key with smart cards. No Yes 
 Performing key ceremony. No Yes 







 What can I do with IBM Cloud Hyper Protect Crypto Services? 

IBM Cloud Hyper Protect Crypto Services can be used for key management service and cryptographic operations.
Optimize and size your new hosts and clusters by using the latest hardware options available in IBM Cloud. Check the latest options in the VMware Solutions console, or contact your local Sales representative for more details.
3. You can deploy the new vCenter Server with NSX-T instance in new VLANs and a new pod, or you can use existing VLANs. 25GE NICs might not be available on the same pod. Also, you cannot move the subnets between VLANs, if, for example, you need to reuse the public IP addresses. Analyze your networking needs and then decide.
4. Migrate your network configurations from NSX-V to NSX-T. As the NSX-T architecture is different, you have the opportunity to design and implement the overlay network and configurations based on NSX-T best practices. NSX-T offers scripting capabilities or you can use Terraform to define your topology. You can alternatively use NSX-T Migration Coordination tool or third-party tools to migrate your existing network configurations, firewall, and load-balancing rules.
5. To minimize network downtime, L2 extension is typically used between NSX-V logical switches and NSX-T overlay segments. You can use either NSX-T Bridging or HCX™ Network Extension here. HCX provides tools for bulk and vMotion migrations, too.
6. After your network configurations are migrated or prepared for migration, you can start to migrate your workloads between the environments. Here you have a choice of various methods. With HCX, you have a single tool to do both L2 extension and migration. You can also use Advanced vMotion and storage vMotion between the environments. In addition, you can use services and tools from [Zerto](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-addingzertodr) or [Veeam](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-veeamvm_overview).
Runs SCSI commands encapsulated by FC frames.



Fibre Channel is only required for IBM Power Systems Virtual Servers, and is handled for you during provisioning.





 Hybrid Cloud setup for SAP 

The following are specific configuration items that you need consideration when planning your SAP landscape, by using your existing on-premises SAP support systems in combination with IBM Cloud® for SAP portfolio to create a Hybrid Cloud setup:



* [SAP Transport Management System (STMS also known as. TMS)](https://help.sap.com/viewer/4a368c163b08418890a406d413933ba7/latest/en-US/44b4a0137acc11d1899e0000e829fbbd.html). Configure STMS based on Transport Groups to prevent file sharing across data centers.
* [SAProuter](https://support.sap.com/en/tools/connectivity-tools/saprouter.html). Provides access to SAP Online Service System (OSS). Use your on-premises SAProuter to access the OSS. This SAProuter can be used through further SAProuter hops if IP-based routing is not allowed between your IBM Cloud-based systems and your on-premises SAProuter. Alternatively, you might consider setting up another SAProuter that is based on one IBM Cloud-based server with a public IP and connect it to the SAP OSS system through the internet.
* [SAP Solution Manager](https://support.sap.com/en/alm/solution-manager.html). Access to the SAP Solution Manager has different connectivity requirements between an SAP Solution Manager and its managed systems. The differences depend on your usage scenario. These scenarios require an understanding of the required network connectivity.
* If you are deploying public gateways or floating IPs, you need to look into the details of Network Address Translation (NAT) and the behavior of SAP applications.
Getting started with Netezza Performance Server time travel 

Time-related data is core to most application databases. With the Netezza Performance Server time travel feature that is available starting from version 11.2.2.5, you can retrieve and analyze historical data without having to develop additional application logic such as history tables. This powerful tool comes in handy when you want to track the history of data changes or reconstruct your data.

By using Netezza Performance Server time travel, you can access historical data (data that was changed or deleted) at past points in time or within a past period of time.

[Create or alter objects](https://cloud.ibm.com/docs/netezza?topic=netezza-enablingdisabling_tt) to start running time travel queries.



  Business use cases and examples 



*  Conducting data audits
You can examine and audit past data because time travel provides an audit trail of data insertions, deletions, and changes to attributes over the course of business activity.
For example:



*  Identify the price of an item before the holiday discount season.
*  Identify the price of stock that was used in a valuation or initial public offering three months ago.
*  Identify the financials according to due diligence at the time of a company merger.



*  Analyzing and calculating trends
You can examine how data changes over time, identify differences in the data between two points in time, or analyze trends.
For example:



*  Identify the number of cars that are rented out week over week.
*  Identify the purchaser that makes the most changes to the quantity after an order is entered.
*  Identify the suppliers that routinely offer a steeper discount than first indicated.



*  Rebuilding or reconstructing data
For example:



*  Restore a table to a point in the past (for which the historical data is still available).
*  Restore selected rows that were incorrectly deleted or updated.
: You can deploy IBM Cloud Pak® for Data Version 4.5 on the following versions of Red Hat OpenShift Container Platform:



* Version 4.6.29 or later fixes
* Version 4.8.0 or later fixes
* Version 4.10.0 or later fixes



New IBM Cloud Pak® for Data CLI commands and reference
: Starting in IBM Cloud Pak® for Data Version 4.5, the cpd-cli includes new commands and a new command reference. For more information, see the [cpd-cli command reference](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.5.x?topic=interface-cpd-cli-command-reference).

Microsoft Edge browser support
: Beginning in Version 4.5, Microsoft Edge is fully supported for use with IBM Cloud Pak® for Data. For more information, see [Browser support](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-indexindex-browser-support).

Language support improvements
: Entity recognition and intent classification for Japanese and Korean languages changed to improve the reliability of Watson Assistant. You might see minor differences in how Watson Assistant handles entity recognition and intent classification.

Any visible changes are most likely to be seen in dictionary-based or pattern-based entity matching. For more information about defining entities, see [Adding entities](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-entities). As a suggested practice, you can test your dialog skill with your current test framework to determine whether your workspace is impacted before you update your production workspace.

If entity values or synonyms that previously matched no longer match, you can update the entity and add a synonym with white space between the tokens, for example:



* Japanese: Add “見 た” as a synonym for “見た”
* Korean: Add “잘 자 요” as a synonym for “잘자요”



Assistant preview link can be disabled
: Assistant preview now includes a toggle to disable the preview link.
When you run this script, it takes the data output from the Terraform script and uses the jq facility to parse the content and create the environment variables needed. It then runs the script (server.js) that initializes the database and populates it with data.





 Step 5. Visit your website 



1. Open a browser and visit https://localhost:8080. See the button for each team in the following screen capture:

Zoom

![{Click the button for each team.](https://cloud.ibm.com/docs-content/v1/content/522c6f62358b063f921283400a601c3f9bc66f08/Cloudant/images/teamdir1.png)

Figure 1. Team Directory team selectors
2. Click any of the colored buttons and obtain a list of team members.
3. Look at where the data came from, IBM Cloudant (cache = false) or Databases for Redis (cache = true) and how long it took.
4. Click the same button that you clicked in step two. You can see the data that comes from the Databases for Redis cache and takes a lot less time to execute in the following screen capture:

Zoom

![Click the team button and see the members of the team.](https://cloud.ibm.com/docs-content/v1/content/522c6f62358b063f921283400a601c3f9bc66f08/Cloudant/images/teamdir2.png)

Figure 2. Team Directory team list and cache information

In a real cloud-based application, the application server and the Databases for Redis instance would be close to each other (in the same data center) so latency between the two would be only a few milliseconds. In this example, extra network hops exist between your locally hosted application server and the cloud-hosted Databases for Redis cache so latency gains aren't as good as in production.
About IBM Cloud Floating IPs 

Floating IP addresses are IP addresses that are provided by the system and are reachable from the public internet. They are allocated an IPv4 address which can be used for external connectivity in a number of ways.

You can reserve a floating IP address from the pool of available addresses that are provided by IBM, and you can associate it with a network interface of any instance in the same zone. That interface also will have a private IP address. Each floating IP address can be associated with only one interface or public gateway.

Currently, floating IP supports only IPv4 addresses.



 External connectivity 

External connectivity can be achieved by using either a public gateway that is attached to a subnet, or a floating IP address that is attached to a virtual server instance. Use a public gateway for source network address translation (SNAT) and a floating IP for destination network address translation (DNAT).

Associating a floating IP address with an instance removes the instance from the public gateway's Many-to-1 NAT.

Table 1 summarizes the differences between the options:



Table 1. External connectivity options

 Public gateway Floating IP 

 Instances can initiate connections to the internet, but they can't receive connections from the internet. Instances can initiate or receive connections to or from the internet 
 Provides connectivity for an entire subnet Provides connectivity for a single instance 



For secure external connectivity, use the VPN service to connect your VPC to another network. For more information about VPNs, see [Using VPN with your VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-using-vpn).





 Floating IPs use cases 

Creating a floating IP is a standard way for you to acquire external connectivity for your services.



 Use case 1: External connectivity 

You can create and assign a floating IP to a virtual server instance to provide your service with outbound connectivity to a third-party vendor service or external service. One floating IP can be assigned to multiple virtual server instances and subnets.

The following diagram demonstrates the difference in applying external connectivity to a service through a public gateway and a floating IP address. In this scenario, three virtual server instances are connecting to services and customers through a public gateway and floating IP address.