vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For the list of IP addresses and IP ranges to allow through the firewall, go [here](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=cloud-infrastructure-ibm-cloud-ip-ranges).
* What VPN options are included with each firewall product?

Not all firewalls offer VPN and not all VPN options are the same. The general options for VPN are:



* Each customer receives unlimited SSL VPN connections to our private network. These connections can be established by clicking the VPN link at the top of the page while logged into the IBM Cloud console.
* IBM Cloud also offers a basic multi-tenant IPsecVPN service.
* The FortiGate Security Appliance 1G provides SSL and IPsecVPN options with Public network access only (no access to the IBM Cloud private network). FSA 10G provides SSL and IPsecVPN options with Public or Private network access.
* The Network Gateway provides SSL, IPsecand OpenVPN capabilities on the public or private network
* The NetScaler products can provide SSL and IPsecVPN on the public or private network.
* Customers can also deploy a VPN solution on to a server within their IBM Cloud environment.



* Which firewall products support public-to-private NAT and/or private VLAN segmentation?

Fortigate Security Appliance 10G supports NAT and private VLAN segmentation. The other firewall offerings only support public traffic.



Subnets and IPs



* What does "Primary IP for future server only" mean when I look at a subnet's IP addresses?

Primary subnets are assigned and removed as needed by IBM Cloud for other resources you order, such as bare metal servers or virtual server instances. IP addresses are not assigned one at a time. We assign a subnet, meaning that there is sometimes additional room for future resources. This designation is stating that these addresses will be used by future resources. See [Can I use the other IP addresses that are defined by the primary subnets I see?]
For Entrust DataControl v4.3.2 and later, IBM Cloud for VMware Solutions provides automatic renewal support for Entrust licenses with the Call Home feature enabled. For VMware vCenter Server® instances that are not private-only, Entrust DataControl is deployed with firewall and SNAT (Source Network Address Translation) rules that are defined on the management services ESG mgmt-nsx-edge.

These rules enable internet access for the Entrust virtual machines (VMs). If internet access is not enabled, the license that is applied to your Entrust DataControl installation will expire after a year.

For private-only vCenter Server environments, the VMware® NSX Edge Services Gateway (ESG)mgmt-nsx-edge is not added. Therefore, the firewall and SNAT rules are not defined. As a result, internet connectivity cannot be enabled for private-only instances and Entrust licenses expire annually.



 Procedure to find the firewall and SNAT rules defined 



1. Log in to the VMware vSphere® Web Client (FLEX) and find the ESG mgmt-nsx-edge.
2. Click Home > Networking & Security > NSX Edges.
3. Double-click the ESG mgmt-nsx-edge and click the Manage tab.
4. Go to the Firewall tab and find the Entrust rules. Note the source IP addresses, which are the IP addresses for the Entrust VMs.
5. Go to the NAT tab and find the SNAT rules that are created for the Entrust VMs. The source IP addresses match the IP addresses that you noted in the previous step.







 Procedure to enable internet connectivity for Entrust DataControl 



1. Complete steps 1 - 3 in the previous procedure.
2. Click Settings and then Interfaces. Note the IP address for the private uplink. This address becomes the new default gateway.
3. Click Home > Hosts and Clusters and find the Entrust VMs. Right-click one of the VMs and click Open Console.
4.
IBM Blockchain Platform provides different offerings that allow you to deploy your network in the environment of your choice. You need to decide if you want to deploy the IBM Blockchain Platform 2.5.4 or if you want to use the IBM Blockchain Platform for IBM Cloud.



Table 1. Which offering is right for your business?

 IBM Blockchain Platform for anywhere (2.5.4) IBM Blockchain Platform for IBM Cloud 

 Where do you want to deploy the platform? Multiple Kubernetes distributions on a private, public, or hybrid multicloud <br> <br>See [Supported Platforms](https://www.ibm.com/docs/en/blockchain-platform/2.5.4?topic=started-about-blockchain-platform-254console-ocp-about-prerequisites)) A Kubernetes cluster on IBM Cloud <br> <br>See [Supported configuration](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-overviewibp-console-overview-supported-cfg) 
 What are my deployment options? <br><br> * Full platform<br> * [Only IBM Blockchain images](https://cloud.ibm.com/docs/blockchain?topic=blockchain-get-started-ibpget-started-ibp-images)<br><br><br> <br><br> * Full platform<br><br><br> 
 How is it billed? Contact us for [pricing](https://www.ibm.com/docs/en/blockchain-platform/2.5.4?topic=253-pricing) [$0.29 USD per allocated CPU hour](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-saas-pricing) 
 Can I connect with peers in other clouds? Yes Yes 
 Can my data center be<br><br>on-prem<br><br>and behind a firewall? Yes No
set security firewall name APP-TO-INSIDE rule 110 protocol udp
set security firewall name APP-TO-INSIDE rule 110 destination address ibmprivate
commit
Show more
6. Validate firewall access.



* Confirm INSIDE-TO-APP firewall is now allowing ICMP and UPD/TCP traffic from your local machine.

ping <VSI Private IP Address>
SSH root@<VSI Private IP Address>
* Confirm the APP-TO-INSIDE firewall is allowing ICMP and UPD/TCP traffic. Log in to the VSI using SSH and ping one of the IBM Cloud name servers at 10.0.80.11 and 10.0.80.12.

SSH root@<VSI Private IP Address>
[root@vsi ] ping 10.0.80.11



7. Validate continued access to the VRA management interface via SSH from your workstation. If access is maintained, review and save the configuration. Otherwise, a reboot of the VRA will return back to a working configuration.

SSH vyatta@<VRA Private IP Address>

show security







 Debugging firewall rules 

The firewall logs can be viewed from the VRA operational command prompt. In this configuration, only dropped traffic for each zone is logged to aid in diagnosis of firewall misconfiguration.



1. Review firewall logs for denied traffic. Periodic review of the logs will identify if servers in the APP zone are attempting to validly or erroneously contact services on the IBM network.

show log firewall name INSIDE-TO-APP
show log firewall name APP-TO-INSIDE
2. If services or servers are not contactable and nothing is seen in the firewall logs, verify if the expected ping/ssh IP traffic is present on the VRA network interface from the IBM Cloud private network or on the VRA interface to the VLAN using the <VLAN ID> from earlier.

monitor interface bonding dp0bond0 traffic
monitor interface bonding dp0bond0.<VLAN ID> traffic









 Step 6: Secure the VRA 



1. Apply VRA security policy.
For more information, see [Integrating an IBM Cloud Application Load Balancer for VPC with security groups](https://cloud.ibm.com/docs/vpc?topic=vpc-alb-integration-with-security-groups).





 Access control lists (ACLs) or security groups? 

Although you can use either VPC ACLs or VPC security groups to control inbound traffic to and outbound traffic from your cluster, security groups are easier to implement. You can simplify your security setup by adding rules to only the default security group for your cluster, and leaving the default ACL for your VPC as-is.

To simplify your VPC security setup, leave your default ACL for the VPC as-is or configure inbound and outbound rules either only at the security group level or only at the ACL level. If you configure rules in both ACLs for your subnets and in the default security group for your worker nodes, you might inadvertently block the subnets and ports that are required for necessary traffic to reach your cluster.

Review the following advantages of security groups over ACLs:



* As opposed to ACLs, security group rules are stateful. When you create a rule to allow traffic in one direction, reverse traffic in response to allowed traffic is automatically permitted without the need for another rule. Fewer rules are required to set up your security group than to set up an ACL.
* An ACL must be created for each subnet that your cluster is attached to, but only one security group must be modified for all worker nodes in your cluster.
* ACLs are applied at the level of the VPC subnet. If one cluster uses multiple subnets, rules are required to ensure that the subnets can communicate with each other. If you create multiple clusters that use the same subnets in one VPC, you can't use ACLs to control traffic between the clusters because they share the same subnets.
* With an ACL, you must explicitly allow traffic in both directions for a connection to succeed.
* ibmcloud is security-group-rule-update 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 8daca77a-4980-4d33-8f3e-7038797be8f9 --direction inbound --output JSON







 Command options 



* GROUP: ID or name of the security group.
* RULE_ID: ID of the security group rule.
* --vpc: ID or name of the VPC. It is only required to specify the unique resource by name inside this VPC.
* --direction: Direction of traffic to enforce. One of: inbound, outbound.
* --remote: The set of network interfaces from which this rule allows traffic. It can be specified as either a REMOTE_ADDRESS, CIDR_BLOCK, or SECURITY_GROUP. If unspecified, then traffic is allowed from any source (or to any source, for outbound rules).
* --icmp-type: ICMP traffic type to allow. Valid values from 0 to 254. This option is specified only when protocol is set to icmp. If unspecified, all types are allowed.
* --reset-icmp-type: Reset an existing ICMP traffic type value.
* --icmp-code: ICMP traffic code to allow. Valid values from 0 to 255. This option is specified only when protocol is set to icmp. If unspecified, all codes are allowed.
* --reset-icmp-code: Reset an existing ICMP traffic code value.
* --port-min: Minimum port number. Valid values are from 1 to 65535. This option is specified only when protocol is set to tcp or udp. If unspecified, all ports are allowed (default: 1).
* --reset-port-min: Reset minimum port number.
* --port-max: Maximum port number. Valid values are from 1 to 65535. This option is specified only when protocol is set to tcp or udp.
For more information about ESXi firewall rules, see [NFS client firewall behavior](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-70686ADB-961A-46BD-B814-48DCF6C5E34B.html).

Loss of connectivity to NFS storage
: (Updated on 7 June 2022) See Why did my host lose connection to my NFS datastore?

Edge services cluster updates
: You can now add more than one edge services cluster in the same data center pod.

Price calculation updates
: Price calculations are now automatically generated when you access the VMware vCenter Server instance order page. Default selections include the Data Center SP Professional license for NSX-T, the Advanced license for NSX-V, the Dual Intel® Xeon® Platinum 8260 processor / 48 cores, 2.4 GHz CPU model, and 768 GB RAM.

VMware Subscription Purchasing Program credits - deprecated
: Credits for the VMware Subscription Purchasing Program (SPP) are no longer available.

Add-on services upgrades
: The following service versions are now available to install on deployed instances.



* FortiGate Virtual Appliance v7.0.4
* Entrust DataControl® v5.5 (formerly known as HyTrust® DataControl)
* Red Hat OpenShift v4.9.27
* Zerto v9.0u3



Dizzion
: Dizzion is now available as a featured service from the VMware Solutions console.

Name change for HyTrust add-on services
: The company Entrust acquired the HyTrust company. The names of the following services are updated.



* Entrust CloudControl™
* Entrust DataControl
* Entrust KeyControl™, which is deprecated



Veeam VSI, Veeam bare metal, and Zerto configuration changes
Long-running operations 



 Overview 

A long-running operation is an operation that returns a response with HTTP status code 202 to indicate that the processing for the request will be [performed asynchronously (RFC 7231)](https://datatracker.ietf.org/doc/html/rfc7231section-6.3.3).

An operation that returns a 202 status code SHOULD NOT return any other 2xx status code. In other words, an operation SHOULD NOT be potentially asynchronous, using the status code to specify that processing has already completed.

Here we do not consider operations that return a 200 to signify that a change to a "desired state" has been accepted but will be achieved asynchronously.

Long-running operations MUST provide a means for the client application to determine when an operation has completed and the outcome (success or failure) of the processing. There are two general approaches to providing operation status -- an operation-based approach and a resource-based approach.

In the operation-based approach, the response to the original request MUST contain an operation resource, and the service MUST support a GET operation on the operation resource that returns the operation status. The service MAY also support other operations on the operation resource, such as update or cancel.

The resource-based approach may be used in situations where the resource contains a status field whose value is updated as a result of the operation and is thereafter fixed. A typical scenario is the creation of a resource whose status field indicates when the creation process has completed. When the resource-based approach is used, the response to the original request MUST contain a representation of the subject resource including the resource status field. The normal GET operation for the resource can then be used to poll for the completion of the operation.





 Operation-based long-running operations 

The operation resource MUST contain a status field and this field SHOULD be named status. The status field SHOULD be defined as an enumeration that includes the following values:



* not_started: the processing for the operation has not started
* succeeded: the processing for the operation has completed successfully
* failed: the processing for the operation failed
The ABAP SDK for IBM Watson is available in two variants:



* [ABAP SDK for IBM Watson, using SAP NetWeaver](https://github.com/watson-developer-cloud/abap-sdk-nwas)
* [ABAP SDK for IBM Watson, using SAP Cloud Platform ABAP Environment](https://github.com/watson-developer-cloud/abap-sdk-scp)



It is tested with:



* SAP Business Applications



* SAP S/4HANA
* SAP ECC



* SAP Development Applications



* SAP Cloud Platform ABAP Environment



* SAP Development methods, frameworks, and tools



* ABAP RESTful Application Programming Model
* SAP Fiori UX with SAPUI5 side-by-side extensions





And it adheres to SAP coding standards for application development, such as:



* HTTP(S) / REST calls
* Authentication
* IAM token handling
* JSON <-> DDIC type conversion
* Error handling







 Simple Business Example Use Case 

This example is an end-to-end simplified business example use case for using the ABAP SDK for IBM Watson in multiple ways.



1. ABAP with SAP Fiori + ABAP SDK for IBM Watson on the SAP Cloud Platform, Mobile Services, and ABAP Environment



* Action: Customer uses mobile app to take photo of broken item, identified material by using Visual Recognition
* For example, send request to business to fulfill:



* Submitted photo of asset
* Lookup of material in ERP
* Enact RFQ or PO





2. ABAP with SAP Fiori + ABAP SDK for IBM Watson



* Action: Visual Recognition to check uploaded file before import of document into ERP
* For example, check that uploaded image is:



* A contract document
* The correct contract required
* Has a signature in the required position of the form





3. ABAP with SAP GUI + ABAP SDK for IBM Watson



* Action: Visual Recognition and Language Translation of document that is imported into ERP
* For example, upload contract document in a different language:
* Convert to English
ibmcloud fn property get --auth

Example output

whisk auth kkkkkkkk-kkkk-kkkk-kkkk-kkkkkkkkkkkk:tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt

The string before the colon is your key, and the string after the colon is your token.





 Invoke a mobile SDK action 

To invoke a remote action, you can call invokeAction with the action name. Use a dictionary to pass parameters to the action as needed.

Example

// In this example, we are invoking an action to print a message to the IBM Cloud Functions Console
var params = Dictionary<String, String>()
params["payload"] = "Hi from mobile"
do {
try whisk.invokeAction(name: "helloConsole", package: "mypackage", namespace: "mynamespace", parameters: params, hasResult: false, callback: {(reply, error) -> Void in
if let error = error {
//do something
print("Error invoking Action (error.localizedDescription)")
} else {
print("Action invoked!")
}
})
} catch {
print("Error (error)")
}
Show more





 Fire a mobile SDK trigger 

To fire a remote trigger, you can call the fireTrigger method, and pass in parameters as needed by using a dictionary.

// In this example we are firing a trigger when our location has changed by a certain amount
var locationParams = Dictionary<String, String>()
locationParams["payload"] = "{"lat":41.27093, "lon":-73.77763}"
do {
function(newDoc, oldDoc, userCtx) {
// any update to an existing doc is OK
if(oldDoc) {
return;
}

// reject tombstones for docs we don’t know about
if(newDoc["_deleted"]) {
throw({forbidden : "Deleted document rejected"});
}

return; // Not strictly necessary, but clearer.
}

To use a validate_doc_update function to remove tombstone documents:



1. Stop replication from the source to the target database.
2. If appropriate, delete the target database, then create a new target database.
3. Add a suitable validate_doc_update function, similar to the example provided.
4. Add it to a design document in the target database.
5. Restart replication between the source and the (new) target database.
6. When replication is complete, switch your application logic to use the new database.
7. Verify that your applications work correctly with the new database.



When you're satisfied that everything is working correctly, you might want to delete the old database.

Here is another variation for using the validate_doc_update function to remove tombstone documents if possible.



1. Add some metadata to the tombstone documents, for example, to record the deletion date.
2. Use the function to inspect the metadata and allow deletion documents through if they must be applied to the target database.



This check helps ensure correct replication of the deletion.





 Performance implications of tombstone removal 

Tombstones are used for more consistent deletion of documents from databases. This purpose is especially important for mobile devices: without tombstone documents, a deletion might not replicate correctly to a mobile device, with the result that documents might never be deleted from the device.

If you re-create a database, for example, a new target for a replication. Any clients that use the target database as a server must work through all the changes again because the database sequence numbers are likely to be different.
Application Instance - An Application Instance is a uniquely named copy of App Configuration created by you but managed by IBM. Multiple instances of App Configuration within a single environment are all considered separate application instances, as are individual App Configuration instances in multiple environments (such as test, development, staging, or production).

A single instance of App Configuration can serve multiple environments, and in fact the service is designed to do so.

Active Entity ID - An active entity ID is a unique identifier for each entity that interacts with the App Configuration service. For example, an entity might be an instance of an app that runs on a mobile device, a microservice that runs on the cloud, or a component of infrastructure that runs that microservice. For any entity to interact with App Configuration, it must provide a unique entity ID. This task is most easily accomplished by programming your app or microservice to send the Entity ID by using the App Configuration SDK.

API Call - An API call is the invocation of the App Configuration through a programmable interface.

Exactly what constitutes an API call varies depending on the entity type (for example, a microservice or a mobile app). For server-side entities like microservices, when the state of a feature flag or property changes in the App Configuration, a websocket connection notifies the SDK in the microservice that a state change occurred. The microservice then calls back into the App Configuration to retrieve the update. This action is an API call.

An API call also occurs on startup to the retrieve the initial configuration state. For client-side entities like mobile apps, websockets are not used. Instead, an API call fetches the current configuration state when a user opens the app, or brings it to the foreground. You can also programmatically call the App Configuration to retrieve the most recent configuration state.
* How to view usage metrics for App Configuration?

View basic historical App Configuration usage metrics on the IBM platform [Billing and Usage dashboard](https://cloud.ibm.com/billing/usage).
Advanced Cross vCenter Server vMotion enables the migration of VMs between vCenter Server instances, without the requirement for Enhanced Linked Mode or Hybrid Linked Mode and hence it is now possible to migrate VMs between vCenter appliances that are in different Single Sign-On domains. Advanced Cross vCenter Server vMotion can be used for single VMs or bulk migrations. The source vCenter needs to be version 6.5 or greater.

The vMotion involves a network backing change that might be disruptive. For more information, see [vMotion between VDS/VSS and NSX-T virtual switch](https://kb.vmware.com/s/article/56991).

If you experience any issue during migration, see [Migrating a virtual machine between two different vDS versions](https://kb.vmware.com/s/article/79446).

Zoom

![Migrating network connectivity with NSX-T L2 bridge solution](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/v2t-nsx-t-l2-bridge-3.svg)

Figure 3. Migrating network connectivity with NSX-T L2 bridge solution



1. Before migrating VMs, ensure that you migrated the distributed firewall configuration to allow the required traffic flow to and from the VMs. If you are considering the Migration Coordinator, see [Migrating distributed firewall configuration](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-CFFE8C28-2D32-4AC5-98C2-9F1AEE525190.html).
2. To migrate the VMs hosted on the NSX-V logical switch that is stretched to the NSX-T environment, log in to the vCenter appliance on the vCenter Server with NSX-T environment and initiate the import VMs workflow.