vania-janet/multiturn-rag-retrieval-data huggingface dataset:
This command closes the gRPC connections opened by your gateway. Closing connections save network resources and improve performance.

After completing the edits from this step and Step four, save issue.js and close it. Submit the transaction that creates the new commercial paper by using the following command:

node issue.js

If the transaction is successful, you can see the following output in your terminal:

Transaction complete.
Disconnect from Fabric gateway.
Issue program complete.





 Step six: Operate the sample as Digibank 

After you create the commercial paper by operating as Magnetocorp, you can buy and redeem the commercial paper by operating the tutorial as Digibank. You can use the Digibank application code by using the same organization as Magnetocorp, or use the CA, peers, and connection profile of a different organization. If you competed the [Join a network tutorial](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-join-networkibp-console-join-network), this is a good opportunity operate the tutorial as Org2.

Go to the digibank/application directory. You can follow the directions that are provided in Step three to create to generate the certificates and wallet that will sign the transaction as Digibank. You can then use the buy.js file to purchase the commercial paper from Magnetocorp, and then use redeem.js to redeem the paper. You can follow Step four and Step five to edit those files so that they point to the correct connection profile, channel and smart contract.







 Connecting to your network by using low-level Fabric SDK APIs 

If you are interested in preserving your existing application code, or by using Fabric SDKs for languages other than Node.js, you can still connect to your network by using lower-level Fabric SDK APIs. Use the console to [download your connection profile](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-appibp-console-app-profile).
* Add at least 10 minutes of audio that includes speech, not silence.

The quality of the audio makes a difference when you are determining how much to add. The better the model's audio reflects the characteristics of the audio that is to be recognized, the better the quality of the custom model for speech recognition. If the audio is of good quality, adding more can improve transcription accuracy. But adding even five to ten hours of good quality audio can make a positive difference.
* Add audio resources that are no larger than 100 MB. All audio- and archive-type resources are limited to a maximum size of 100 MB.

To maximize the amount of audio that you can add with a single resource, consider using an audio format that offers compression. For more information, see [Data limits and compression](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-audio-formatsaudio-formats-limits).
* Divide large audio files into multiple smaller files. Make sure to split the audio between words, at points of silence.

Because you can submit multiple simultaneous requests to add different audio resources, you can add smaller files concurrently. This parallel approach to adding audio resources can accelerate the service's analysis of your audio.
* Add audio content that reflects the acoustic channel conditions of the audio that you plan to transcribe. For example, if your application deals with audio that has background noise from a moving vehicle, use the same type of data to build the custom model.
* Make sure that the sampling rate of an audio file matches the sampling rate of the base model for the custom acoustic model:



* For broadband models, the sampling rate must be at least 16 kHz (16,000 samples per second).
* For narrowband models, the sampling rate must be at least 8 kHz (8000 samples per second).



If the sampling rate of the audio is higher than the minimum required sampling rate, the service downsamples the audio to the appropriate rate. If the sampling rate of the audio is lower than the minimum required rate, the service labels the audio file as invalid. If any audio file that is contained in an archive file is invalid, the service considers the entire archive invalid.
Getting started with IBM Maximo Application Suite Dedicated 

![MAS Dedicated Site Banner](https://cloud.ibm.com/docs-content/v1/content/bd177462727ef0a849ddcf8c842a6203b41f0625/mas-ms/images/MAS-MS-Site-Banner.jpg)



 About 

Maximo Application Suite Dedicated (MAS-Dedicated) provides IBM managed provisioning, installation, configuration, operational support, security, maintenance and administration of Maximo Application Suite for customers on the IBM Cloud and AWS platforms. MAS-Dedicated combines key IBM technologies: Red Hat Open Shift, IBM Cloud Pak for Data and IBM Watson - into a focused MAS services solution, allowing customers to make implementation of product functionality & features a priority.

Please note the Maximo Application Suite Managed Services was renamed MAS Dedicated in December 2022. Client who purchased MAS Managed Services will remain on the Shared Cluster deployment option (see [Maintenance](https://cloud.ibm.com/docs/mas-ms?topic=mas-ms-maintenance) page for details and differences between shared cluster deployment option and the dedicated cluster deployment option). Clients on the shared cluster can contract their sales representative to discuss the upgrade to the dedicated service if needed.





 Before you begin 

Before you can use Maximo Application Suite Dedicated, environments must first be ordered and provisioned by the IBM MAS-Dedicated operations team. To obtain more information about the MAS-Dedicated offering and available options, please contact your IBM Salesperson or an Authorized IBM Partner. If you do not have an IBM Saleperson or Authorized reseller, please complete and submit the consultation form (link below). An IBM representative will be in contact with you.

[https://www.ibm.com/products/maximo?schedulerform=](https://www.ibm.com/products/maximo?schedulerform=)





 Part Numbers and Order Considerations 

This section details the part numbers and considerations when placing an order for Maximo Application Suite Dedicated.

Before submitting an order, the following should be considered to ensure the order is 'right sized' and will meet the requirements of the client.
JSON response 

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.error+json",
"collectionTotal": 1
},
"resources": [
{
"errorMsg": "Bad Request: Instance policy could not be created. Please see reasons for more details.",
"reasons":
{
"code": "NUM_COLLECTION_RESOURCE_ERR",
"message": "Only a single instance policy may be created per query parameter. Please pass single resource object",
"status": 400,
"moreInfo": "https://cloud.ibm.com/apidocs/key-protect"
}
]
}
]
}











 16 - Only imported keys may be restored 



 Message 

Only imported keys may be restored

Reason code: KEY_IMPT_REQ_ERR





 HTTP status code 

400 - Bad Request

The HTTP 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

The client should not repeat this request without modification.





 Context 

Key Protect can restore a previously deleted root key, which restores access to its associated data in the cloud.

As an admin, you might need to restore a root key that was imported into Key Protect to access data the key previously protected.

When you restore a key, you move the key from the Destroyed (state value is 5) to the Active (state value is 1) key state, and you restore access to any data that was previously encrypted with the key.

You can restore a deleted key within 30 days of its deletion. This capability is available only for root keys that were created with a key material, also known as the "payload."

You can only restore root keys that were created with a key material, using the kp key create command with the -k, --key-material option.
Open a browser and check out the app with the following URL: http://<public_IP_address>:<NodePort>. With the example values, the URL is http://169.xx.xxx.xxx:30872. You can give this URL to a co-worker to try or enter it in your cell phone's browser so that you can see that the app really is publicly available. Note: Because worker nodes in VPC clusters don't have a public IP address, you can access an app through a NodePort only if you are connected to your private VPC network, such as through a VPN connection. Then, you can use the worker node's private IP address and NodePort: http://<private_IP_address>:<NodePort>.
4. [Launch the Kubernetes dashboard](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appcli_dashboard).

If you select your cluster in the [IBM Cloud console](https://cloud.ibm.com/), you can use the Kubernetes Dashboard button to launch your dashboard with one click.
5. In the Workloads tab, you can see the resources that you created.



Good job! Your app is deployed in a container!
FAQs for Direct Link on Classic 

You can review answers to some frequently asked questions about IBM Cloud® Direct Link.



 How does Direct Link on Classic differ from the new Direct Link offering? 

The new IBM Cloud Direct Link offering differs from "Direct Link on Classic" in that the new Direct Link is decoupled from classic IaaS, and exists only in the local cross-connect router (XCR). This design enables native connectivity to VPC and future capabilities without being forced into the classic IaaS network.

The zone-region model allows for multiple data centers to exist in a single zone.

The new Direct Link offering allows connectivity to both Classic IaaS as well as VPCs, whereas the Classic Direct Link always connects to IaaS network and a global VRF first. Classic Direct Link can only reach VPC on a limited basis utilizing a VPC feature called Classic Access and by adding global routing to the direct link. For more information, see [Setting up access to your Classic Infrastructure from VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructure).

For information about the differences between the new Direct Link offerings and the "on Classic" versions, see [How do I know which Direct Link solution to order?](https://cloud.ibm.com/docs/direct-link?topic=direct-link-get-started-with-ibm-cloud-direct-linkget-started-solution-to-order) and [Getting started with IBM Cloud Direct Link Dedicated](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl).





 How does IBM Cloud Direct Link work? 

For every Direct Link customer, the IBM Cloud® team assigns a small private subnet to build a point-to-point network between the IBM Cloud cross-connect router (XCR) and the customer's edge router (CER). Then, IBM Cloud and the customer configure Border Gateway Protocol (BGP) to exchange routes between the environments.
If you want to specify a default rule for all events that were not processed by other rules you would specify the rule ("locations" : [""]) as the final rule in your rules definition for the route.
* If an event doesn't match any rule and no default target is configured, the event will be dropped and not routed to any target.
* Any update to a rules configuration must include all location rules. An update will discard the existing rule set and replace it with the specified configuration.
* You can manage routes in your account by using the Activity Tracker Event Routing CLI, and programmatically by using the Activity Tracker Event Routing REST API and Terraform scripts.
* To manage routes, you need IAM permissions. For more information, see [Activity Tracker Event Routing actions](https://cloud.ibm.com/docs/atracker?topic=atracker-iam&interface=cliplatform).







 Collecting auditing events 

To collect auditing events in your IBM Cloud account, you can configure Activity Tracker Event Routing by using the Activity Tracker Event Routing API, the Activity Tracker Event Routing CLI and Terraform scripts.

The IBM Cloud® Activity Tracker Event Routing feature has been enhanced and a new API version 2 is available. To use the new V2 features and configurations, your existing Activity Tracker Event Routing V1 account configuration must be migrated to an Activity Tracker Event Routing V2 account configuration.

If you configured IBM Cloud® Activity Tracker Event Routing prior to 16 May 2022, you will need to migrate your configuration to the new version V2. The IBM Cloud® Activity Tracker Event Routing API version 1 is deprecated. For more information, see [Migrating the Activity Tracker Event Routing account configuration from V1 to V2](https://cloud.ibm.com/docs/atracker?topic=atracker-migration&interface=cli).

For more in formation, see [Collecting events](https://cloud.ibm.com/docs/atracker?topic=atracker-events_collect&interface=cli).





 What are the API V2 enhancements? 

The following table outlines key feature differences between Activity Tracker Event Routing API versions:



Table 1.
Secondary subnets in the unrouted state may be subject to automatic reclaim. Refer to the [FAQs](https://cloud.ibm.com/docs/subnets?topic=subnets-faqfaq-unrouted-subnets-automatic-reclaim) for more details on this policy.



 Features and use cases 

Secondary subnets have the following features:



* Data center and globally routable public IPv4 and IPv6 IP addresses
* Data center routable private IPv4 IP addresses
* IPv4 /32 to /24 and IPv6 /64 blocks available
* Provide unique IP addresses to virtual machines capable of portability across hosts
* Address your services individually, maintaining a stable IP address when migrating to new compute resources
* High availability configurations, which use virtual/floating IP address protocols
* Route to a disaster recovery site in any data center that uses a global IP
* Can be routed and unrouted on demand as application needs change. For more information, see [Re-routing secondary subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-re-routing-secondary-subnets).



Secondary subnets provide you with multiple IP addresses for many needs. Use secondary subnets when you need a stable IP address that does not depend on any specific compute device. Example uses include:



* IP addresses that you can assign to your own, local, virtual machines
* Multiple, distinct service IP addresses hosted by a single server allowing you to easily identify traffic (commonly used with web servers and TLS)
* A service IP address that is tied to DNS, so you can avoid DNS caching delays when shifting workloads to new servers; in other words, the service IP won't change simply because a server's primary IP address does
* High availability configurations, which use floating IP address protocols



IBM offers different routing options for secondary subnets. To help illustrate the differences between these routing options, the following example is referenced in further explanations.

Available IP addresses provided by the subnet 10.0.0.0/29:

10.0.0.0
10.0.0.1
10.0.0.2
You don't need to resize or rebalance the worker pool manually.





 Following scalable deployment practices 

Make the most out of the cluster autoscaler by using the following strategies for your worker node and workload deployment strategies. For more information, see the [Kubernetes Cluster Autoscaler FAQs](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md).

[Try out the cluster autoscaler](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helm) with a few test workloads to get a good feel for how [scale-up and scale-down work](https://cloud.ibm.com/docs/openshift?topic=openshift-caca_about), what [custom values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_chart_values) you might want to configure, and any other aspects that you might want, like [overprovisioning](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-deploy-appsca_scaleup) worker nodes or [limiting apps](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-deploy-apps). Then, clean up your test environment and plan to include these custom values and additional settings with a fresh installation of the cluster autoscaler.



 Can I autoscale multiple worker pools at once? 

Yes, after you install the cluster autoscaler, you can choose which worker pools within the cluster to autoscale [in the ConfigMap](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-enable). You can run only one autoscaler per cluster. Create and enable autoscaling on worker pools other than the default worker pool, because the default worker pool has system components that can prevent automatically scaling down.
You don't need to resize or rebalance the worker pool manually.





 Following scalable deployment practices 

Make the most out of the cluster autoscaler by using the following strategies for your worker node and workload deployment strategies. For more information, see the [Kubernetes Cluster Autoscaler FAQs](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md).

[Try out the cluster autoscaler](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helm) with a few test workloads to get a good feel for how [scale-up and scale-down work](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpcca_about), what [custom values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_chart_values) you might want to configure, and any other aspects that you might want, like [overprovisioning](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-deploy-appsca_scaleup) worker nodes or [limiting apps](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-deploy-apps). Then, clean up your test environment and plan to include these custom values and additional settings with a fresh installation of the cluster autoscaler.



 Can I autoscale multiple worker pools at once? 

Yes, after you install the cluster autoscaler, you can choose which worker pools within the cluster to autoscale [in the ConfigMap](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-enable). You can run only one autoscaler per cluster. Create and enable autoscaling on worker pools other than the default worker pool, because the default worker pool has system components that can prevent automatically scaling down.
You don't need to resize or rebalance the worker pool manually.





 Following scalable deployment practices 

Make the most out of the cluster autoscaler by using the following strategies for your worker node and workload deployment strategies. For more information, see the [Kubernetes Cluster Autoscaler FAQs](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md).

[Try out the cluster autoscaler](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helm) with a few test workloads to get a good feel for how [scale-up and scale-down work](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-classic-vpcca_about), what [custom values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_chart_values) you might want to configure, and any other aspects that you might want, like [overprovisioning](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-deploy-appsca_scaleup) worker nodes or [limiting apps](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-deploy-apps). Then, clean up your test environment and plan to include these custom values and additional settings with a fresh installation of the cluster autoscaler.



 Can I autoscale multiple worker pools at once? 

Yes, after you install the cluster autoscaler, you can choose which worker pools within the cluster to autoscale [in the ConfigMap](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-enable). You can run only one autoscaler per cluster. Create and enable autoscaling on worker pools other than the default worker pool, because the default worker pool has system components that can prevent automatically scaling down.
When you use service insertion and after, deploy a service instance, you can configure the type of traffic that the router redirects to the service. Configuring traffic redirection is similar to configuring a firewall.
6. Alternatively, you can add the device into north-south traffic path and customize the NSX-T customer topology. Contact your third-party vendor to discuss the wanted network topology, for example, router mode versus transparent.



The following diagram presents the routing topology and routing for this pattern.

Zoom

![Network topology with third-party router or firewall in converged or management clusters](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-nsx-t-3rd-party-topo.svg)

Figure 3. Network topology with third-party router or firewall in converged or management clusters

This architecture pattern deployment is summarized as follows:



1. You can deploy third-party network devices into vCenter Server clusters by bringing in your own license and following the hardware and software guidance as provided by the specific third-party vendor. Discuss the technical details with the vendor.
2. You can attach the private interface of the appliance into the IBM Cloud private network by using the IBM Cloud private VLAN. You can use IBM Cloud private portable IP addresses for the appliance.
3. You can attach the public interface of the appliance into the IBM Cloud public network. You can use IBM Cloud public portable IP addresses for the appliance.
4. You can remove or disable the public uplinks on T0. If you do, remove the default route as well.
5. Create an NSX-T overlay segment for a transit network between the T0 and the third-party device. Add T0 uplink and an interface in the third-party device and establish static or dynamic routing between them.
6.
cocoa evidence upload --backend=git --artifact <url> <hash> --artifact <url> <hash> --issue <issue-url> --issue <issue-url> --git-provider='github'

artifact consists of a URL that points to the artifact file and a hash, provide these items in the same way as in the previous example.





 cocoa evidence summarize 

Queries evidence from the Evidence Locker and generates an Evidence Summary from their contents. Backends can be different evidence locker types, such as Object Storage or GitHub. Currently, git and cos are supported as backend. Different lockers require different parameters to be provided.

Required Environment Variables for Git:

EVIDENCE_REPO_ORG= Use this environment varibale to provide the owner organisation of the evidence repository (Required if you are using 'git' backend)
EVIDENCE_REPO_NAME= Use this environment varibale to provide the name of the evidence repository (Required if you are using 'git' backend)
PIPELINE_RUN_ID= Can be used instead of '--pipeline-run-id' option
TOOLCHAIN_CRN= Can be used instead of '--toolchain-crn' option

Required Environment Variables, if you are using GitHub:

GHE_TOKEN= Github Enterprise API Token (Optional if you are using --git-token-path)

Options for Git:

--backend (Required) Specifies the type of locker from where the evidences are queried
--repo Evidence Repositories name (can be substituted by EVIDENCE_REPO_NAME environment variable)
--org Evidence Repositories owner organisation (can be substituted by EVIDENCE_REPO_ORG environment variable)
--pipeline-run-id (Required)
--toolchain-crn (Required)
--prefix-list (Required) a list of paths separated by comma where evidences can be found in the repository
--output (Optional) file name to write the evidence summary into
--git-token-path (Optional) Github Token's path