vania-janet/multiturn-rag-retrieval-data huggingface dataset:
curl -X POST "$vpc_api_endpoint/v1/shares/$replica_id?/failover?version=2023-06-20&generation=2"&maturity=beta -H "Authorization: $iam_token" -d '{
"fallback_policy": "fail",
"timeout": 600
}'

A successful response indicates that the file share failover request was accepted.

You can use the API to verify that replication failover succeeded, is pending, or failed. Make a GET /shares/{replica_id} call. Look at the latest_job property. For more information, see [Verify replication with the API](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-manage-replication&interface=apifs-verify-replica-api).





 Failover with Terraform 

When a failover is performed, replica share becomes the source, and the source share becomes replica. The terraform configuration needs to be modified to match this. The fallback_policy defines the action to take if the failover request is accepted but cannot be performed or times out. Accepted values are split or fail. If you specify split and the failover is unsuccessful, the system breaks the replication relationship, and the two file shares become independent of each other.

resource "ibm_is_share_replica_operations" "test" {
share_replica = ibm_is_share.replica.id
fallback_policy = "split"
timeout = 500
}

For more information about the arguments and attributes, see [ibm_is_share_replica_operations](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/ibm_is_share_replica_operations).





 Next steps 

[Manage replication](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-manage-replication).
Action is failing 

  What’s happening 

The action is failing.

  Why it’s happening 

One explanation for a failing app is that a deprecated runtime is being used. An action cannot be completed successfully until the runtime is updated to a supported one.

  How to fix it 

To see which runtime is used for the action, run ibmcloud fn action get ACTION_NAME and check for deprecated=true in the query response. If the runtime is deprecated, [update the runtime](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-actionsactions_update). For more information, see [Runtimes](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-runtimes).
(https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-console-build-network-troubleshoot-entry1)
* [Why does my peer or ordering node fail to start?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-console-build-network-troubleshoot-entry2)
* [Why does my blockchain node fail to restart?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-restart)
* [What is the proper way to clean up a failed node deployment?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-cleanup)
* [How can I view my smart contract container logs?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-console-smart-contracts-troubleshoot-entry2)
* [Why is my CA, peer, or ordering node that is configured to use HSM not working?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-hsm-proxy)
* [Why are my transactions returning an endorsement policy error: signature set did not satisfy policy?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-endorsement-sig-failure)
* [Why are the transactions I submit from VS Code failing with a No endorsement plan available error?]
service_desk.sip.transfer_method refer Determines how to transfer the call:<br><br><br><br> * refer: The call is transferred by sending a SIP REFER request. This is the default value.<br> * hangup: The call is transferred by sending a SIP BYE request.<br><br><br> 
 service_desk.sip.transfer_target_header Transfer-Target The SIP header that contains the transfer target when a BYE request is used for transferring the call. This option is supported only in the hangup method. 
 service_desk.sip.transfer_headers N/A A list of custom header field name/value pairs to be added to a transfer request 
 service_desk.sip.transfer_headers_send_method custom_header The method by which the SIP transfer headers are sent:<br><br><br><br> * custom_header: Sends the transfer headers as part of the SIP message. This is the default value.<br> * contact_header: Sends the transfer headers in the Contact header. This option is not supported in the hangup method.<br> * refer_to_header: Sends the transfer headers in the Refer-To header. This option is not supported in the hangup method.<br><br><br> 



If you define a SIP URI as the transfer target, escape the at sign (@) in the URI by adding two backslashes (\) in front of it. This is to prevent the string from being recognized as part of the entity shorthand syntax.

"uri": "sip:12345556789\@myhost.com"



 Transferring after hangup 

By default, the phone integration transfers calls by using a SIP REFER request. Depending on the IVR service provider, you might need to configure call transfer to use a SIP BYE request instead. Use the transfer_method attribute to specify how to transfer the call, using either refer or hangup. When transfer_method is set to hangup instead of refer, the behavior of the transfer action changes.
Correcting readiness errors and warnings 

Readiness errors and warnings can inhibit your ability to successfully complete a readiness check. This topic provides information on correcting different types of errors and warnings.



 Correcting connectivity errors 

There are two categories of connectivity errors that you might encounter when performing readiness checks:



* Host (Ubuntu) SSH connectivity errors
* Gateway (vSRX) SSH connectivity errors



Many of these errors result from the fact that the gateway actions being checked require root SSH access to the private IP address for either the host (Ubuntu) OS, or the gateway (vSRX). If an SSH connectivity check fails, then the action cannot proceed.

For more information about establishing an SSH session, see [Accessing the device using SSH](https://cloud.ibm.com/docs/vsrx?topic=vsrx-performing-ibm-cloud-juniper-vsrx-basicsaccessing-the-device-using-ssh). Note that for step 3, the example given is with the admin user. For a readiness check, substitute the root user for both the vSRX and the Hardware (host). Also, make sure that you use your private IP with this procedure, not your public IP.

To validate connectivity, open an SSH session to either the Ubuntu host's or vSRX's private IP using the root credentials listed in the Hardware section (for an Ubuntu host) or the vSRX section (for the gateway) of the [Gateway Appliance Details](https://cloud.ibm.com/docs/vsrx?topic=gateway-appliance-viewing-gateway-appliance-details) page. Ensure that the SSH session can be established.

If the session cannot be established, check the following potential issues.

For host (Ubuntu) SSH connectivity errors:



* Is the Ubuntu firewall blocking SSH access to the private IP? The firewall rules must allow SSH access to the private 10.0.0.0/8 subnet.
Common headers and error codes 

Data transfers use many standard protocols and have unique requirements. Keep up-to-date with the reference to common headers and some error codes.



 Error Codes 



 Error Code Description HTTP Status Code 

 AccessDenied Access Denied 403 Forbidden 
 BadDigest The Content-MD5 that you specified did not match what we received. 400 Bad Request 
 BucketAlreadyExists The requested bucket name isn't available. The bucket namespace is shared by all users of the system. Please select a different name and try again. 409 Conflict 
 BucketAlreadyOwnedByYou Your previous request to create the named bucket that is succeeded and you already own it. 409 Conflict 
 BucketNotEmpty The bucket that you tried to delete isn't empty. 409 Conflict 
 CredentialsNotSupported This request does not support credentials. 400 Bad Request 
 EntityTooSmall Your proposed upload is smaller than the minimum allowed object size. 400 Bad Request 
 EntityTooLarge Your proposed upload exceeds the maximum allowed object size. 400 Bad Request 
 IncompleteBody You did not provide the number of bytes specified by the Content-Length HTTP header. 400 Bad Request 
 IncorrectNumberOfFilesInPostRequest POST requires exactly one file upload per request. 400 Bad Request 
 InlineDataTooLarge Inline data exceeds the maximum allowed size. 400 Bad Request 
 InternalError We encountered an internal error. Please try again. 500 Internal Server Error 
 InvalidAccessKeyId The AWS access key Id that you provided does not exist in our records. 403 Forbidden 
 InvalidArgument Invalid Argument 400 Bad Request 
 InvalidBucketName The specified bucket is not valid. 400 Bad Request 
 InvalidBucketState The request is not valid with the current state of the bucket. 409 Conflict 
 InvalidDigest The Content-MD5 that you specified is not valid. 400 Bad Request 
 InvalidLocationConstraint The specified location constraint is not valid. For more information about regions, see How to Select a Region for Your Buckets. 400 Bad Request
Using Configure mode, run the merge or load command, specifying one of the latest config.boot files from the preceding example, then commit. The errors will show the cause of the problem, so you should delete any invalid configurations and add valid ones as necessary. Repeat this process and resolve all issues until the commit succeeds and the Vyatta returns to its previously working state.

You can upgrade your other VRAs without having to repeat this process by making the same changes on those devices before you attempt an update. Fixing these issues before running the upgrade allows subsequent updates to work.

Report all bugs that you find during this process by opening a [support case](https://cloud.ibm.com/docs/virtual-router-appliance?topic=gateway-appliance-getting-help) so that the vendor can fix these issues in later releases.





 Upgrading from 1801 to 1912 

You might encounter these common issues when upgrading from 1801 to 1912:

Many Bash commands no longer work
: By version 1912, a security feature called [user-isolation](https://docs.vyatta.com/en/release-notes/earlier-releases/earlier-releases/vnos-release-notes-1903/new-featurestopic-6481) was enabled by default, which creates a shell session where commands for accessing the underlying Debian system are limited. To fix this, commit the line set system login user-isolation disable in your configuration and then log in again.

Problems with time zones that contain 3 locations
: Time zones that contain 3 locations, such as America/Kentucky/Monticello, can cause a complete failure of your upgrade, which results in the VRA entering a factory reset condition. To fix this issue, set the time zone to one that has only 2 locations.
: This issue, [VRVDR-52825](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-at-t-vyatta-5600-vrouter-software-patches1912g), was fixed in version 1912g.

Port ranges starting with 0 instead of 1
Webhooks have a failure policy that indicates whether Kubernetes can ignore connection errors when calling the webhook or whether connection error must fail the operation. A ValidatingWebhookConfiguration resource inspects the request while a MutatingWebhookConfiguration resource modifies the request data before it is processed.

Webhooks can also deny requests as part of normal operation: A webhook might deny requests that violate security policies or it might perform other data validation. In such cases the failure information will contain a "denied the request" response with a reason indicating the problem.

 {: pre}
admission webhook "mutate.configuration.upsert.appconnect.ibm.com" denied the request: version is not supported


In Red Hat OpenShift on IBM Cloud, webhooks that call services running in the cluster do so by using a secure tunnel that connects the cluster control plane in an IBM Cloud account to cluster worker nodes in your customer account.

 How to fix it 

Complete the following steps to identify the webhook that is causing the issue. Then debug the related service and remove or recreate your webhook if needed.



1. Run the following command to get the VPN pod logs. If you can't get the VPN logs, follow the steps to [Debug common CLI issues](https://cloud.ibm.com/docs/openshift?topic=openshift-ts_clis) and return to this page when you are able to retrieve the logs. If the command succeeds and you can get the logs, the VPN tunnel is working and you can continue to the next step.
2. Describe your admission control webhooks and save the output to a file called webhooks.txt.

kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
3. Review the webhooks.txt file for error messages. Webhook related error messages from an application, including oc, can help to identify the webhook.
4.
Webhooks have a failure policy that indicates whether Kubernetes can ignore connection errors when calling the webhook or whether connection error must fail the operation. A ValidatingWebhookConfiguration resource inspects the request while a MutatingWebhookConfiguration resource modifies the request data before it is processed.

Webhooks can also deny requests as part of normal operation: A webhook might deny requests that violate security policies or it might perform other data validation. In such cases the failure information will contain a "denied the request" response with a reason indicating the problem.

 {: pre}
admission webhook "mutate.configuration.upsert.appconnect.ibm.com" denied the request: version is not supported


In IBM Cloud Kubernetes Service, webhooks that call services running in the cluster do so by using a secure tunnel that connects the cluster control plane in an IBM Cloud account to cluster worker nodes in your customer account.

 How to fix it 

Complete the following steps to identify the webhook that is causing the issue. Then debug the related service and remove or recreate your webhook if needed.



1. Run the following command to get the VPN pod logs. If you can't get the VPN logs, follow the steps to [Debug common CLI issues](https://cloud.ibm.com/docs/containers?topic=containers-ts_clis) and return to this page when you are able to retrieve the logs. If the command succeeds and you can get the logs, the VPN tunnel is working and you can continue to the next step.
2. Describe your admission control webhooks and save the output to a file called webhooks.txt.

kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
3. Review the webhooks.txt file for error messages. Webhook related error messages from an application, including kubectl, can help to identify the webhook.
4.
To inquire about the status of your ticket, follow the steps in [Contacting IBM Support](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-trbl_support).







 What to do next 

Manage your instances from the VMware Solutions console or the VMware vSphere Web Client.

Review the following topics for information to help you complete the login instructions:



* For the requirements and necessary steps before you access the vSphere Web Client, see [Timeout reached while connecting to the vSphere Web Client](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-trbl_timeout_vc_console).
* For a list of access points to log in to the IBM Cloud infrastructure Private Network by using VPN, see [VPN access](https://www.ibm.com/cloud/vpn-access).
* If you have problems when you deploy an OVF (Open Virtualization Format) file by using the vSphere Web Client, see [Deploying an OVF file using the vSphere Web Client](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-trbl_deploy_ovf).







 Related links 



* [Procedure to order VMware vSphere instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_orderinginstances-procedure)
* [Adding ESXi servers to VMware vSphere instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_addingservers)
* [Deleting VMware vSphere instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_deletinginstances)
You have gathered all of your peer or ordering service certificates from your third-party CA, created their corresponding organization MSP definition and created a peer or ordering service. If you are following along in the tutorials, you can return to the next step.



* If you created the peer node, the next step is to [Create the node that orders transactions](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-networkibp-console-build-network-create-orderer).
* If you created the node to join an existing network, the next step is to [Add your organization to list of organizations that can transact](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-join-networkibp-console-join-network-add-org2).
* If you created an ordering service, the next step is to [Create a channel](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-networkibp-console-build-network-create-channel).











 Configuring a node to use a Hardware Security Module (HSM) 

Key management is a critical aspect of managing a blockchain network. Because private keys are not stored by the platform, users are responsible for downloading and securing the private key of their node identities. In a production network, when a higher level of security is required for private keys, an HSM is an optional hardware appliance that performs cryptographic operations and provides the capability to ensure that the private keys never leave the HSM. Currently, Hyperledger Fabric supports HSM devices that implement the

[PKCS #11 standard](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html). PKCS #11 is a cryptographic standard for secure operations, generation, and storage of keys.

The ability to configure a node to use HSM is available only in paid clusters.
(https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-sc-install)
* [Why is my Node.js smart contract fail to endorse?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-nodejs-endorsement)
* [Why is the smart contract that I installed on the peer not listed in the UI?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-console-build-network-troubleshoot-missing-sc)
* [My channel, smart contracts, and identities have disappeared from the console. How can I get them back?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-browser-storage)
* [Why am I getting the error Unable to authenticate with the enroll ID and secret you provided when I create a new organization MSP definition?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-create-msp)
* [Why am I getting the error An error occurred when updating channel when I try to add an organization to my channel?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-update-channel)
* [When I log in to my console, why am I getting a 401 unauthorized error?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-console-401)
FAIL: Could not create request: dial tcp 169.62.10.162:443: connect: connection refused
=== Check connectivity to 169.63.75.82:443 ===
FAIL: Could not create request: dial tcp 169.63.75.82:443: connect: connection refused
=== Check connectivity to 169.63.88.178:443 ===
PASS: got response back from 169.63.88.178:443
=== Check connectivity to 169.63.88.186:443 ===
PASS: got response back from 169.63.88.186:443
=== Check connectivity to 169.63.94.210:443 ===
FAIL: Could not create request: dial tcp 169.63.94.210:443: connect: connection refused
=== Check connectivity to 169.63.111.82:443 ===
FAIL: Could not create request: dial tcp 169.63.111.82:443: connect: connection refused
=== Check connectivity to 169.63.149.122:443 ===
FAIL: Could not create request: dial tcp 169.63.149.122:443: connect: connection refused
=== Check connectivity to 169.63.158.82:443 ===
FAIL: Could not create request: dial tcp 169.63.158.82:443: connect: connection refused
=== Check connectivity to 169.63.160.130:443 ===
FAIL: Could not create request: dial tcp 169.63.160.130:443: connect: connection refused
=== Check connectivity to link control plane ===
=== Test Failure Summary: ===
redhatOS - error checking RHN configuration with subscription-manager: exit status 1
network - wrong number of network interfaces (expected 2, found: 3: [1: lo, 2: eth0, 3: eth1])
network - Could not create request: dial tcp 169.62.10.162:443: connect: connection refused
Be sure to insert your application choice in place of aaaaaaaa (IBM Cloud® Virtual Router Appliance, Juniper vSRX, or Fortigate Security Appliance (FSA) 10G), and your specific account number in place of xxxxxx in your subject line.
* Wanclouds, our partner in this conversion configuration process, has completed several hundred successful migration engagements. They transform your existing Vyatta 5400 to create similar functionality on the Vyatta 5600 Platform. They provide their services in two tiers:

![Tiers](https://cloud.ibm.com/docs/images/tiers.png)

Service tiers



See [Migrating Vyatta 5400](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-migration-overview) to get started.
* Are there any additional paid migration services available from IBM Business Partners for migrating off the Vyatta 5400?

We have several business partners who provide paid support for Vyatta 5400 migrations. For more information, see the [End of Support Announcement](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-vyatta-5400-end-of-support-announcement).
* Is there a Vyatta 5400 Offering Management support contact in IBM where I can ask questions related to my Vyatta 5400 migration?

Contact IBM Vyatta 5400 and VRA Network Offering Management with questions at nwom@us.ibm.com. You can also contact them using slack with the IBM Watson Cloud Platform workspace: vyatta-migration
* What additional resources are available to help me with this migration?

Review the following IBM Cloud® Virtual Router Appliance documentation resources for more information:



* [Getting Started with IBM Cloud® Virtual Router Appliance](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-getting-started)