vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Preview actions 

Most action templates are complete. (Starter kit templates are marked with an asterisk and require setup.) You can try out an action right away even without making any changes.

To preview the action that you created from a template:



1. In the actions editor, click Preview.
2. Try some of the example phrases from Customer starts with to see how the assistant responds.

Zoom

![Preview](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/actions-templates-preview.png)

Preview







 Starter kit extension setup 

Starter kit templates add actions that can use extensions to connect to data and systems outside of Watson Assistant. To learn more about extensions in general, see [Build a custom extension](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-build-custom-extension).

It's important to add the extension to your assistant first, so the starter kit actions can detect the installed extension. Don't add the starter kit actions without adding the extension first.

This table lists each starter kit, a link to download an OpenAPI specification file that you need to set up the extension, and a link to setup instructions.



Starter kits

 Starter kit OpenAPI specification file Setup instructions 

 Coveo search [coveo.openapi.json](https://github.com/watson-developer-cloud/assistant-toolkit/blob/master/integrations/extensions/starter-kits/coveo/coveo.openapi.json) [Coveo search setup](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-actions-templatesactions-templates-extension-setup-coveo)
Although you cannot choose which worker node an ordering node is deployed to, the console is configured with an anti-affinity policy. This means that for high availability, whenever you deploy a blockchain node on a multi-node cluster, the console attempts to spread ordering nodes that belong to the same organization across the worker nodes if sufficient resources are available. If your cluster is configured with multiple zones, you can designate which zone the ordering node is deployed to when you create it, or you can let the console choose for you. In this case, it also leverages the anti-affinity policy across zones.

A minimum of five ordering nodes is recommended for a production ordering service. In Raft, a majority of the total number of nodes is needed to form a [quorum](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-quorum). In other words, if you have one node, you need that node available to have a quorum because the majority of one is one. Similarly, if you have two nodes, you will need both available, since the majority of two is two. In a similar vein, the majority of five is three. This means that in a five node configuration, the loss of two nodes can be tolerated and ensures zero downtime. You can see in the diagram that Region 1 contains two ordering nodes, Region 2 contains one ordering node, and Region 3 contains two ordering nodes. Spreading the nodes across the regions guarantees that if any single region goes down, or if the ordering nodes within it need to be offline for maintenance, that quorum can be maintained by the nodes in the other regions.

The tutorial walks you through the following steps:



1. Deploy the ordering service in Region 1.
2. Add a new ordering node in Region 2.
3. Add two new ordering nodes in Region 3.
4. Update the ordering service in Region 1, Region 2, and Region 3.





 Before you begin 

This tutorial assumes that you have three Kubernetes clusters that are deployed across three different regions and that you have linked a blockchain service instance to each of those clusters.

Choose the regions of your Kubernetes clusters carefully.
In the Additional BGP settings section, you can activate one or more of these optional settings. Make sure to enable the switch for each section before configuring the settings.



* Verify data integrity with Message Digest 5 (MD5) - Add an extra layer of security between two BGP peers by verifying each transmitted message sent through the BGP session. When MD5 authentication is activated, BGP authenticates every segment sent over the TCP session from its peer and verifies the source of each routing update.

Important:



* You must configure the same BGP MD5 authentication key on both your Edge router and the IBM cross-connect router (XCR). The shared authentication key on the IBM device must be stored in your HPCS or Key Protect instance and shared with the Direct Link service. For more information, see [Setting up BGP Message Digest 5 (MD5) authentication keys](https://cloud.ibm.com/docs/dl?topic=dl-dl-md5).
* You can achieve hitless key refresh if the keys are updated on both your Edge router and on the IBM cross-connect router (XCR) within 90 seconds. As a pre-condition, you must configure the BGP hold time on your router to a minimum of 90 seconds. All Direct Link routers have a 90-second configuration by default. Either side can initiate the key refresh, but both sides must refresh within the configured BGP hold time to avoid traffic disruption.
* If a BGP peering session was established and you enable BGP MD5 authentication (or change the authentication key to a different value), BGP sessions are re-established, which causes BGP session downtime and network disruption until the BGP peer device is configured with the same change.



Complete the following information:



* For the keystore, select either Hyper Protect Crypto Services or Key Protect.
* Select an authentication keystore instance.
* Select an authentication key.



* Detect network failures with Bidirectional Forwarding Detection (BFD) - Activate BFD to quickly detect faults in a network between two routers or switches that are connected by a link.
In other words, if you have one node, you need that node available to have a quorum, because the majority of one is one. While satisfying the quorum makes sure that the ordering service is functioning, production networks also have to think about deployment configurations that are highly available (in other words, configurations in which the loss of a certain number of nodes can be tolerated by the system). Typically, this means tolerating the loss of two nodes: one node going down during a normal maintenance cycle, and another going down for any other reason (such as a power outage or error).

This is why, by default, the console offers two options: one node or five nodes. Recall that the majority of five is three. This means that in a five node configuration, the loss of two nodes can be tolerated. Users who know that they will be deploying a production solution should therefore choose the five node option.

However many nodes a user chooses to deploy, they have the ability to add more nodes to their ordering service. For more information, see [Adding and removing ordering service nodes](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-add-remove-orderer).





 Deployment zone selection 

If your Kubernetes cluster is configured across multiple zones, when you deploy an ordering node you have the option of selecting which zone the node is deployed to. Check the Advanced deployment option that is labeled Deployment zone selection to see the list of zones that is currently configured for your Kubernetes cluster.

For a five node ordering service, these nodes will be distributed into multiple zones by default, depending on the relative space available in each zone. You also have the ability to distribute a five node ordering service yourself by clearing the default option to have the zones that are chosen for you and distributing these nodes into the zones you have available. You can check which zone a node was deployed to by opening the tile of the node and looking under the Node location. Alternatively, you can use the APIs to deploy an ordering node to a specific zone.
In this scenario, you want to run workloads in a classic cluster that are accessible to services, databases, or other resources in your on-premises data center. However, you might need to provide limited public access to your cluster, and want to ensure that any public access is controlled and isolated in your cluster. For example, you might need your workers to access an IBM Cloud service that does not support private cloud service endpoints, and must be accessed over the public network. Or you might need to provide limited public access to an app that runs in your cluster. To achieve this cluster setup, you can configure a gateway appliance, such as a Virtual Router Appliance (Vyatta), as a public gateway and firewall.

Zoom

![Architecture image for a cluster that uses a gateway appliance for secure public access.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_clusters_planning_gateway.png)

Figure 1. Network setup for a cluster that uses a gateway appliance for secure public access



 Worker-to-worker communication, worker-to-master and user-to-master communication with a gateway appliance 

If you set up your worker nodes on a private VLAN only and you don’t want to or can't enable VRF for your account, you must configure a gateway appliance to provide network connectivity between your worker nodes and the master over the public network. For example, you might choose to set up a [Virtual Router Appliance](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-about-the-vra) or a [Fortigate Security Appliance](https://cloud.ibm.com/docs/vmwaresolutions/services?topic=vmwaresolutions-fsa_considerations).
If you are using the [public repository](https://github.com/IBM/ibm-spectrum-scale-ibm-cloud-schematics) that is provided by IBM Cloud, then set this variable as template_repo_request_model['url'] = 'https://github.com/IBM/ibm-spectrum-scale-ibm-cloud-schematics'; otherwise, set it to the private repository you are using.



4. Inside the schematics_service.create_workspace function, provide the following parameters:



* Provide an optional description.
* Provide a name to identify your Schematics workspace, for example, terraform-dev-workspace.
* Change the type parameter to the Terraform version that you are using to create IBM Cloud resources, for example, terraform_v0.13.
* Change the location to a region where your Schematics workspace needs to be created, for example, us-south.
* Change the resource group to the resource group where your resources should be grouped, for example, Default for a default resource group.
* If you are using a private GitHub repository, provide your personal GitHub access token that you set up in [Setting up the IBM Cloud Schematics](https://cloud.ibm.com/docs/hpc-spectrum-scale?topic=hpc-spectrum-scale-setting-up-api) prerequisites in the x_github_token= "<github-api-token>" parameter. If you are using the public repository that is provided by IBM Cloud, you do not need to specify this parameter.
* Optional: Provide the tags if you want to filter resources by using the tag.



5. Run the Python script by using python3 <python-file-name> to create a Schematics workspace in the IBM Cloud.
6. You get a successful response if the parameters passed as part of the request are valid and you should be able to see the Schematics workspace that you created in the IBM Cloud console. If you don’t get a successful response, the error response contains the errors that you need to resolve.
Debugging Connectors 

To troubleshoot your issues quickly and efficiently, it is highly recommended that you connect your Satellite Connector instance to an IBM Log Analysis instance.

Access your Satellite Connector instance from the console. If you don’t have an IBM Log Analysis instance in your account for the region you created the Satellite Connector in, click Connect under the Logging for Link section. You will be taken to the Catalog page where you can create an IBM Log Analysis instance. If you already have an IBM Log Analysis instance, click Configure under the Logging for Link section. Then, select your existing logging instance. After you’ve connected an IBM Log Analysis instance to your Satellite Connector, you can use the Logging for Link section to open the Logging Instance dashboard and the output will be filtered for your Connector.

The logging instance must have Receive Platform Logs enabled. To enable this option, select Options -> Edit Platform from the list of logging instances.

Typically there are two types of errors:



1. The tunnel cannot be established. The agent does not show up in the Active Agents tab on the console.
2. The tunnel is established and you can see the agent in the list of Active Agents, but you cannot access an on-prem application from IBM Cloud using an endpoint.





 Tunnel cannot be established - Agent does not show up on list of Active Agents 

The tunnel does not get established and you don’t see your Satellite Connector Agent showing up in the list on the UI under the “Active Agents” tab.

There is approximately a 2-minute delay from when the Connector Agent starts to when it shows up in the list.

After 2 minutes, if the agent is still not displaying, follow these debugging steps:



1. Verify that the Connector ID and region are specified correctly.
2. Open the Logging Dashboard and review the Connector logs. Often, the issue is with the IAM API key and you see a message similar to the following example. For more information, see [Why isn't my API key working](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-connector-api).
* Provide the workspace ID that you generated in the [Creating a workspace](https://cloud.ibm.com/docs/hpc-slurm?topic=hpc-slurm-creating-workspace&interface=apiexample-request-create) task, for example, us-south.workspace.Terraform-Schematics-Python-Workspace.b3bbc9f5.
* Provide an activity ID that was generated as a successful response for the specific action for which you want to retrieve logs. You received an activity ID when you successfully completed the action in the Schematics workspace.



5. Run the Python script by using python3 <python-file-name> to retrieve the logs for an action for your Schematics workspace in the IBM Cloud.
6. You get an action ID, name, and action status, such as COMPLETED or FAILED, in response when it is determined whether the parameters passed as part of the request are valid. You should be able to retrieve the logs for an action for a specific Schematics workspace. If you don’t get a successful response, the error response contains the errors that you need to resolve. Resolve those errors and run the script until you are able to get a valid response and can retrieve the logs.





 Example Python request 

 Retrieve Schematics workspace action details using Python API

import json, logging

from ibm_cloud_sdk_core.authenticators import IAMAuthenticator
from ibm_schematics.schematics_v1 import SchematicsV1

logging.basicConfig()
logging.root.setLevel(logging.NOTSET)
logging.basicConfig(level=logging.NOTSET)

authenticator = IAMAuthenticator('<ibmcloud-api-key>')

schematics_service = SchematicsV1(authenticator = authenticator)

schematics_service.set_service_url('https://us.schematics.cloud.ibm.com')

logging.info("Started Retrieving the Schematic logs")
* Provide the workspace ID that you generated in the [Creating a workspace](https://cloud.ibm.com/docs/ibm-spectrum-lsf?topic=ibm-spectrum-lsf-creating-workspace) task, for example, us-south.workspace.Terraform-Schematics-Python-Workspace.b3bbc9f5.
* Provide an activity ID that was generated as a successful response for the specific action for which you want to retrieve logs. You received an activity ID when you successfully completed the action in the Schematics workspace.



5. Run the Python script by using python3 <python-file-name> to retrieve the logs for an action for your Schematics workspace in the IBM Cloud.
6. You get an action ID, name, and action status, such as COMPLETED or FAILED, in response when it is determined whether the parameters passed as part of the request are valid. You should be able to retrieve the logs for an action for a specific Schematics workspace. If you don’t get a successful response, the error response contains the errors that you need to resolve. Resolve those errors and run the script until you are able to get a valid response and can retrieve the logs.





 Example Python request 

 Retrieve Schematics workspace action details using Python API

import json, logging

from ibm_cloud_sdk_core.authenticators import IAMAuthenticator
from ibm_schematics.schematics_v1 import SchematicsV1

logging.basicConfig()
logging.root.setLevel(logging.NOTSET)
logging.basicConfig(level=logging.NOTSET)

authenticator = IAMAuthenticator('<ibmcloud-api-key>')

schematics_service = SchematicsV1(authenticator = authenticator)

schematics_service.set_service_url('https://us.schematics.cloud.ibm.com')

logging.info("Started Retrieving the Schematic logs")

workspace_activity = schematics_service.get_workspace_activity(
* Provide the workspace ID that you generated in the [Creating a workspace](https://cloud.ibm.com/docs/hpc-spectrum-symphony?topic=hpc-spectrum-symphony-creating-workspace&interface=api) task, for example, us-south.workspace.Terraform-Schematics-Python-Workspace.b3bbc9f5.
* Provide an activity ID that was generated as a successful response for the specific action for which you want to retrieve logs. You received an activity ID when you successfully completed the action in the Schematics workspace.



5. Run the Python script by using python3 <python-file-name> to retrieve the logs for an action for your Schematics workspace in the IBM Cloud.
6. You get an action ID, name, and action status, such as COMPLETED or FAILED, in response when it is determined whether the parameters passed as part of the request are valid. You should be able to retrieve the logs for an action for a specific Schematics workspace. If you don’t get a successful response, the error response contains the errors that you need to resolve. Resolve those errors and run the script until you are able to get a valid response and can retrieve the logs.





 Example Python request 

 Retrieve Schematics workspace action details using Python API

import json, logging

from ibm_cloud_sdk_core.authenticators import IAMAuthenticator
from ibm_schematics.schematics_v1 import SchematicsV1

logging.basicConfig()
logging.root.setLevel(logging.NOTSET)
logging.basicConfig(level=logging.NOTSET)

authenticator = IAMAuthenticator('<ibmcloud-api-key>')

schematics_service = SchematicsV1(authenticator = authenticator)

schematics_service.set_service_url('https://us.schematics.cloud.ibm.com')

logging.info("Started Retrieving the Schematic logs")

workspace_activity = schematics_service.get_workspace_activity(
* Provide the workspace ID that you generated in the [Creating a workspace](https://cloud.ibm.com/docs/hpc-openshift?topic=hpc-openshift-creating-workspace&interface=api) task, for example, us-south.workspace.Terraform-Schematics-Python-Workspace.b3bbc9f5.
* Provide an activity ID that was generated as a successful response for the specific action for which you want to retrieve logs. You received an activity ID when you successfully completed the action in the Schematics workspace.



5. Run the Python script by using python3 <python-file-name> to retrieve the logs for an action for your Schematics workspace in the IBM Cloud.
6. You get an action ID, name, and action status, such as COMPLETED or FAILED, in response when it is determined whether the parameters passed as part of the request are valid. You should be able to retrieve the logs for an action for a specific Schematics workspace. If you don’t get a successful response, the error response contains the errors that you need to resolve. Resolve those errors and run the script until you are able to get a valid response and can retrieve the logs.





 Example Python request 

 Retrieve Schematics workspace action details using Python API

import json, logging

from ibm_cloud_sdk_core.authenticators import IAMAuthenticator
from ibm_schematics.schematics_v1 import SchematicsV1

logging.basicConfig()
logging.root.setLevel(logging.NOTSET)
logging.basicConfig(level=logging.NOTSET)

authenticator = IAMAuthenticator('<ibmcloud-api-key>')

schematics_service = SchematicsV1(authenticator = authenticator)

schematics_service.set_service_url('https://us.schematics.cloud.ibm.com')

logging.info("Started Retrieving the Schematic logs")

workspace_activity = schematics_service.get_workspace_activity(
If you don’t want output from a build job, configure a folder as output and don’t send any output to that folder.

Similar to how you can define pipeline properties, you can also define stage properties for use in all of the jobs in a particular stage. For example, you might define a TEST_URL property that passes a URL to the deploy and test jobs in a stage. The deploy job deploys to that URL and the test job tests the running app at the URL. Stage properties are also passed to job scripts by using environment variables. If the same property is defined at both the pipeline level and the stage level, the value of the stage property is used.

By default in a stage, builds and deployments are run automatically every time that changes are delivered to a project's SCM repository. Stages and jobs run serially; they enable flow control for your work. For example, you might place a test stage before a deployment stage. If the tests in the test stage fail, the deployment stage does not run.

The Delivery Pipeline uses public and private workers to run the jobs in a stage. By default, pipeline jobs are run by using public workers on IBM-managed public shared infrastructure.

In certain scenarios, your Delivery Pipeline might require access to internal or on-premises resources. In these situations, you can connect to and integrate a Delivery Pipeline Private Worker to run on your own Kubernetes infrastructure.

You might want tighter control of a specific stage. If you do not want a stage to run every time that a change occurs at its input, you can disable the capability. On the INPUT tab, in the Stage Trigger section, click Run jobs only when this stage is run manually.

Zoom

![Input tab](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/input_tab_only_execute.png)

Figure 1. Input tab

More stage trigger options are available for stages that use the Git repository input type.
See [Why is my Connector Agent unable to establish the tunnel with IBM Cloud](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-connector-tunnel).
5. Verify that you are using the correct container hardware platform. For example, you are trying to run the agent image on an arm64 platform. The connector agent will only run on linux/amd64 platforms or those platforms that can emulate amd64. If this is the case, you will see an error similar to:

{"msg":"exec container process /usr/local/bin/node: Exec format error","level":"error","time":"2023-06-16T14:37:54.000567792Z"}

Note for Apple Mac silicon users: If you are trying out the Connector on a Mac with Apple silicon which uses an ARM64 processor, the container agent will run if Rosetta2 has been installed. This is normally installed with Docker. When running the Connector Agent, you will see the following warning:

icr.io/ibm/satellite-connector/satellite-connector-agent:v1.0.3 WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested 43064456c42434f056348a32773a732d02d4a68690fc6b2b36790be8daa49bb2

In this case, this is just a warning and the Connector Agent is running. If you don’t want to see the warning, you can specify the --platform linux/amd64 option on your docker run command.
6. Verify that the container platform can pull the image. The image is located in the IBM Container Registry at icr.io/ibm/satellite-connector/satellite-connector-agent:<version>. Make sure you have specified the image correctly. The machine running the agent has network access to icr.io, and that you have logged in to the IBM Container Registry.