vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Load balancers help to distribute your traffic across multiple origin pools.

Follow these steps to create a load balancer:

To set up a global load balancer, you must first create an origin pool.



1. From the DNS Services navigation menu, click Global load balancers, then select the Load balancers tab.
2. Select a DNS zone from the list.
3. Click Create load balancer.
4. Enter the DNS Balancer hostname to associate it with your load balancer.
5. Optionally, enter a Description for the global load balancer.
6. Select the TTL (time-to-live) of the DNS entry for the IP address returned by this load balancer.
7. Add or select a Default policy. A default policy specifies which origin pools are used for all availability zones (AZ) for which a location-based policy is not specified. When multiple pools are selected within a policy, you can change their priority by using the arrow keys in the Priority column.
8. Add or select a Fallback policy. A fallback policy specifies the origin pool to use when all other origin pools in the default or location policy are in a critical state. There can be only one origin pool in the fallback policy.
9. Optionally, add or select a Location policy. The location policy allows you to associate one or more origin pools for a specific AZ. Any AZ that is not explicitly defined as a location policy uses the default policy.





 How DNS resolvers prioritize global load balancing pools 

The DNS resolver uses the following order to return origins from the origin pool.

Location policy > Default policy > Fallback policy

The location policy (if one is defined in the AZ), has the highest priority and is used first. If every origin pool in the location policy is down, then the DNS resolver uses origin pools from default policy. If all of the origin pools in the default policy are also down, then the DNS resolver goes to the origin pool designated in the fallback policy.





 How DNS resolvers handle resource record TTLs for DNS responses
The daemon set modifies the settings for all existing worker nodes and applies the settings to any new worker nodes that are provisioned in the cluster. The init container makes sure that these modifications occur before other pods are scheduled on the worker node. No pods are affected.

You must have the [Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for all namespaces to run the sample privileged initContainer. After the containers for the deployments are initialized, the privileges are dropped.

Before you begin: [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



1. Save the following daemon set in a file named worker-node-kernel-settings.yaml. In the spec.template.spec.initContainers section, add the fields and values for the sysctl parameters that you want to tune. This example daemon set changes the default maximum number of connections that are allowed in the environment via the net.core.somaxconn setting and the ephemeral port range via the net.ipv4.ip_local_port_range setting.

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: kernel-optimization
namespace: kube-system
labels:
tier: management
app: kernel-optimization
spec:
selector:
matchLabels:
name: kernel-optimization
template:
metadata:
labels:
name: kernel-optimization
spec:
hostNetwork: true
hostPID: true
hostIPC: true
initContainers:
- command:
- sh
- -c
- sysctl -w net.ipv4.ip_local_port_range="1025 65535"; sysctl -w net.core.somaxconn=32768;
image: alpine:3.6
Setting advanced rules 

After your CDN is running, you can set advanced rules to optimize network performance. For example, control access through geoblocking, or protect your content from hotlinking.



1. On the CDN page, select your CDN. When the Overview page appears, select the Advanced rules tab.
2. Click Add rule. A window appears where you can configure your rule.
3. Provide a path. For example, use a global path /* (www.example.com/), or a subpath /home/example/ (www.example.com/home/example/).
4. Select a rule type to configure behavior settings. Choices are as follows:

If using a subpath like /home/example/, token authentication is currently the only supported rule type.



* Geographical access control - Select the filter type, location type, and continents (or countries/regions) that you want to allow or deny access to your domain. If you do not specify a configuration for geographical access control, all countries/regions are allowed. For more information, see [Geographical access control](https://cloud.ibm.com/docs/CDN?topic=CDN-about-content-delivery-networks-cdn-geographical-access-control).
* Hotlink protection - Select the protection type and provide the referer URLs (separated by a space) that you want to allow or deny website access to your CDN. For more information, see [Hotlink protection](https://cloud.ibm.com/docs/CDN?topic=CDN-about-content-delivery-networks-cdn-hotlink-protection).
* Token authentication - Provide the token key, set the escape input and ignore query string, and then select the HMAC algorithm. Optionally, specify the token name, token delimiter, ACL delimiter, and transition key. If you do not specify a value for an optional parameter, the default value is used.
Setting up local clients to work with Git source control 

You can manage and work with source code locally in a GitHub or Git Repos and Issue Tracking repository (repo). To work locally, clone your repo with a Git client such as the Git command line interface, and edit the code with your favorite editor. If you work in Eclipse, you can install the EGit plug-in for version control.



 Cloning your Git project from the command line 



 Before you begin 



1. To access the Git server outside the browser, you must create a personal access token or SSH key for authentication. The following table shows what you need to do to set up authentication.



Table 1. Git authentication setup

 Git Type HTTPS Setup HTTPS Use SSH Setup 

 Git Repos and Issue Tracking [Personal access token](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-git_workingcreate_pat) Git Repos and Issue tracking user name (not your IBM id) and personal access token [Configure the SSH key](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-git_workingcreating-an-ssh-key) 
 Public GitHub (github.com) Personal access token is not required, but you can set one up and use it GitHub user name and password, or GitHub user name and Personal Access token, or just the personal access token as the user name [Configure a GitHub SSH key](https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/) 



If you prefer to use SSH, you can reuse a single key across all Git servers. Create or locate your key and configure it in each server as described in the previous links. If you create your key with a passphrase, you are prompted for that passphrase when you use the key.
2.
* To create and set an environment variable for your job, use the --env option with the [job create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-create), [job update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-update), [jobrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-submit), or [jobrun resubmit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-resubmit) command. The following example creates the myjob job that uses the icr.io/codeengine/codeengine image, and defines the envA environment variable.

ibmcloud ce job create --name myjob --image icr.io/codeengine/codeengine --env envA=A
* To update environment variables for an existing job, use the --env option with the [job update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-update), [jobrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-submit), or [jobrun resubmit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-resubmit) command.



Example 1

The following example updates the myjob job to overwrite the value of envA and adds the envB environment variable.

ibmcloud ce job update --name myjob --env envA=AA --env envB=B

Run the job get command to display details of the job, including its environment variables.

ibmcloud ce job get --name myjob

Example output

Getting job 'myjob'...
OK
Setting IBM IAM authentication 

Set your authentication method to IBMIAM with the [REGISTER EXTERNAL AUTHENTICATION SYSTEM SQL statement](https://www.ibm.com/docs/en/netezza?topic=reference-register-external-authentication).

Two factor authentication is not supported with an external authentication system.



 Syntax 

REGISTER EXTERNAL AUTHENTICATION SYSTEM 'IBMIAM' with { PRODUCTION | STAGING | DEVELOPMENT }





 Setting IBM IAM authentication with the web console 



1. [Log in to the web console](https://cloud.ibm.com/docs/netezza?topic=netezza-getstarted-console) as an admin user.
2. Go to the Query editor.
3. Register an IBM IAM external authentication system. Specify the PRODUCTION environment type.

REGISTER EXTERNAL AUTHENTICATION SYSTEM 'IBMIAM' with 'PRODUCTION'
4. Create a user or users with the external authentication method set to IBM IAM as desribed in [Creating users](https://cloud.ibm.com/docs/netezza?topic=netezza-users-groupscreate-users).
5. Verify whether the user was created successfully.



1. Go to Users and groups > Users.
2. Locate the user.
3. Check the Authentication type section for the user.









 Setting IBM IAM authentication with the command-line 



1. [Connect to Netezza Performance Server](https://cloud.ibm.com/docs/netezza?topic=netezza-connecting-overview) as an admin user.

In the example, the ['nzsql' command](https://www.ibm.com/docs/en/netezza?topic=anpssbun-log-2) is used. You can also use the [the ODBC or JDBC drivers](https://www.ibm.com/docs/en/netezza?topic=dls-overview-odbc-jdbc-ole-db-net-go-driver-3).
set security vpn ipsec ike-group <ike group name> proposal 1
set security vpn ipsec ike-group <ike group name> proposal 1 encryption <ike encryption>
set security vpn ipsec ike-group <ike group name> proposal 1 hash <ike hash>
set security vpn ipsec ike-group <ike group name> proposal 1 dh-group 2
set security vpn ipsec ike-group <ike group name> lifetime <ike-lifetime>
3. Create Encapsulating Security Payload (ESP) group

set security vpn ipsec esp-group <esp group name> proposal 1 encryption <esp encryption>
set security vpn ipsec esp-group <esp group name> proposal 1 hash <esp hash>
set security vpn ipsec esp-group <esp group name> lifetime <esp-lifetime>
set security vpn ipsec esp-group <esp group name> mode tunnel
set security vpn ipsec esp-group <esp group name> pfs enable
4. Define site-to-site connection

set security vpn ipsec site-to-site peer <DC VPN Public IP> authentication mode pre-shared-secret
set security vpn ipsec site-to-site peer <DC VPN Public IP> authentication pre-shared-secret <Shared-Secret>
set security vpn ipsec site-to-site peer <DC VPN Public IP> connection-type initiate
set security vpn ipsec site-to-site peer <DC VPN Public IP> ike-group <ike group name>
set security vpn ipsec site-to-site peer <DC VPN Public IP> local-address <VRA Public IP>
set security vpn ipsec site-to-site peer <DC VPN Public IP> default-esp-group <esp group name>
set security vpn ipsec site-to-site peer <DC VPN Public IP> tunnel 1
set security vpn ipsec site-to-site peer <DC VPN Public IP> tunnel 1 protocol gre
commit
The following steps will set the resource limits in the deploymentConfig



1. Make sure the script to generate traffic is running.
2. Switch to the Administrator perspective.
3. Navigate to Workloads > DeploymentConfigs.
4. Select the example-health project.
5. From the Actions menu (the three vertical dots) of patient-health-frontend, choose Edit DeploymentConfig.

Zoom

![Deployments](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution55-openshift-microservices/ocp48-deploymentconfigs.png)

Deployments
6. Under the YAML view, find the section spec > template > spec > containers, add the following resource limits into the empty resources. Replace the resources {}, and ensure the spacing is correct -- YAML uses strict indentation.

resources:
limits:
cpu: 30m
memory: 100Mi
requests:
cpu: 3m
memory: 40Mi

Here is a snippet after you have made the changes:

ports:
- containerPort: 8080
protocol: TCP
resources:
limits:
cpu: 30m
memory: 100Mi
requests:
cpu: 3m
memory: 40Mi
terminationMessagePath: /dev/termination-log
7. Save to apply the changes.
8. Verify that the replication controller has been changed by navigating to Events tab:

Zoom

![Resource Limits](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution55-openshift-microservices/ocp48-dc-events.png)

Resource Limits
To set up the NFS client, run the following job on your z/OS virtual server instance.

//NFSCLNT JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID.,
// REGION=0M
//
//* Configuration for the NFS client. 
//
//ALIAS EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=
//SYSIN DD 
DEF ALIAS(NAME(MVSCLNT) RELATE(CATALOG.VS01.SYS)) -
CAT(CATALOG.VS01.MASTER)
/
//DEFLOG1 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=
//LOG1 DD DSN=MVSCLNT.LOG1,
// DISP=(NEW,CATLG),UNIT=3390,SPACE=(CYL,(2,5),RLSE),
// RECFM=VB,LRECL=137,BLKSIZE=6144,VOL=SER=OPEVS1
//
//DEFLOG2 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=
//LOG2 DD DSN=MVSCLNT.LOG2,
// DISP=(NEW,CATLG),UNIT=3390,SPACE=(CYL,(2,5),RLSE),
// RECFM=VB,LRECL=137,BLKSIZE=6144,VOL=SER=OPEVS1
//
//DEFRACF EXEC PGM=IKJEFT01
//SYSPRINT DD SYSOUT=
//SYSTSPRT DD SYSOUT=
//SYSTSIN DD 
RDEFINE STARTED MVSNFSC.* UACC(NONE) +
STDATA(USER(SYSTEM) GROUP(SYS1) TRUSTED(YES))

SETR REFRESH RACLIST(STARTED)
/
Setting up the Satellite location control plane 

The location control plane runs resources that are managed by Satellite to help manage the hosts, clusters, and other resources that you attach to the location.

When you set up the Satellite location control plane, keep in mind the following host considerations.



* Attach compute hosts in multiples of 3, such as 6, 9, or 12.
* Determine the the correct [size of your location](https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizing).
* Ensure your control plane meets the [suggested high-availability configuration](https://cloud.ibm.com/docs/satellite?topic=satellite-hasatellite-ha-setup) for network redundancy, distribution across physical locations, and so on.
* Make sure that your hosts meet the [latency requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-service-architecturearchitecture-latency).





 Setting up the control plane from the console 

Use the Satellite console to set up a control plane for your location.

Before you begin



* [Attach the required number of hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts) to your location for your Satellite control plane. For more information about sizing requirements, see [sizing your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizing). For cloud provider-specific configurations, see [Cloud infrastructure providers](https://cloud.ibm.com/docs/satellite?topic=satellite-infrastructure-plan).
* Verify that your location is in an Action required state.



To attach hosts as worker nodes to the control plane,



1. From the Satellite [Locations dashboard](https://cloud.ibm.com/satellite/locations), select the location where you want to finish the setup of your control plane.
2. From the Hosts tab, select the hosts to assign as worker nodes to your control plane. All hosts must be in an Unassigned status.
3. From the actions menu of each host, click Assign host.
Enable Enable access to classic resource.
5. Enable Create a default prefix for each zone.
6. Under New subnet for VPC:



* Type vpc1-region1-zone1-mgmt as your subnet's unique name.
* Select a Resource group.
* Select a Location and zone 1. For example, London and London 1.
* Select the number of IP addresses.



7. Set Subnet access control list to Use VPC default.
8. Set the Public gateway to Detached.
9. Click Create virtual private cloud.





 Create the subnet for the web server in the same region 



1. Click Subnets > Create and in the New Subnet for VPC window type vpc-region1-zone1-subnet1 as a unique name for your subnet.
2. Select vpc-region1 as the VPC.
3. Select a Resource group.
4. Select a zone 1 location. For example, London 1.
5. Select the number of IP addresses.
6. Set Subnet access control list to VPC default.
7. Set the Public gateway to Detached.
8. Click Create virtual private cloud.



To confirm the creation of the subnets, click Subnets on the left pane and wait until the status changes to Available.





 Create subnet in a different zone for the other web server 



1. Click Subnets > Create and in the New Subnet for VPC window type vpc-region1-zone2-subnet1 as a unique name for your subnet.
2. Select a Resource group.
3. Select a zone 2 location. For example, London 2.
4. Select the number of IP addresses.
5. Set Virtual Private Cloud.
6. Set the Public gateway to Detached.
7. Click Create subnet.



To confirm the creation of the subnet, click Subnets on the left pane and wait until the status changes to Available.







 Step 2: Create two security groups
Save this information to a JSON file on your local system so that is can be provided when you create your CA.





 Creating an HA CA 

Create a new CA by using the IBM Blockchain Platform console.



1. Navigate to the Nodes tab on the left and click Add Certificate Authority.
2. Make sure that the option to Create a Certificate Authority is selected. Then click Next.
3. Give your CA a display name and enter your CA admin credentials by specifying a CA administrator enroll ID and secret.
4. Click the Database and replica sets selection checkbox under Advanced deployment options and click Next. If your network is on IBM Cloud, this option is only available on paid clusters.
5. To use replica sets, select PostgreSQL as the CA database.
6. Click Add file and browse to the JSON file you created with the database connection information.
7. Choose the number of replica sets you need. Two replica sets ensure that if one CA replica becomes unavailable, the other is always immediately ready to process requests. Three replica sets provide even greater redundancy. If two of the three replica sets are unavailable, the third is ready to process requests. Because each additional replica set requires additional CPU and memory, you need to ensure you have adequate resources available to accommodate the number you choose. This value can be updated later as well.
8. You have the opportunity to configure resource allocation for the node. The resources that you specify here are used for each replica set. If you want to learn more about how to allocate resources in IBM Cloud for your node, see this topic on [allocating resources](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-allocate-resources).
9. Review the Summary page, then click Add certificate authority.
addMembersToAccessGroupOptions.SetMembers(groupMembers)
addGroupMembersResponse, response, err := iamAccessGroupsService.AddMembersToAccessGroup(addMembersToAccessGroupOptions)
if err != nil {
panic(err)
}
b, _ := json.MarshalIndent(addGroupMembersResponse, "", " ")
fmt.Println(string(b))

const groupMember1 = {
iam_id: 'IBMid-user1',
type: 'user',
};
const groupMember2 = {
iam_id: 'iam-ServiceId-123',
type: 'service',
};
const params = {
accessGroupId: testGroupId,
members: [groupMember1, groupMember2],
};

iamAccessGroupsService.addMembersToAccessGroup(params)
.then(res => {
console.log(JSON.stringify(res.result, null, 2));
})
.catch(err => {
console.warn(err)
});

Or, you can give users access by adding trusted profiles to your access groups. For more information, see [What makes a good trusted profiles strategy?](https://cloud.ibm.com/docs/account?topic=account-account_setuptrustedprofiles_strategy) and [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile&interface=api).



 Adding users expected response 



* Curl
* Java
* Python
* Go
* Node



{
"members": [
{
"iam_id": "$IBM_ID",
"type": "user",
: In the spec volume claim templates spec resources requests section, if you want to provision [performance storage](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storagefile_predefined_storageclass), enter the number of IOPS. If you use an endurance storage class and specify a number of IOPS, the number of IOPS is ignored. Instead, the IOPS that is specified in your storage class is used.

storageClassName
: In the spec volume claim templates spec section, enter the storage class that you want to use. To list existing storage classes, run oc get storageclasses | grep file. If you don't specify a storage class, the PVC is created with the default storage class that is set in your cluster. Make sure that the default storage class uses the ibm.io/ibmc-file provisioner so that your stateful set is provisioned with File Storage for Classic.
4. Create your stateful set.

oc apply -f statefulset.yaml
5. Wait for your stateful set to be deployed.

oc describe statefulset <statefulset_name>



To see the current status of your PVCs, run oc get pvc. The name of your PVC is formatted as <volume_name>-<statefulset_name>-<replica_number>.





 Static provisioning: Using an existing PVC with your stateful set 

You can pre-provision your PVCs before creating your stateful set or use existing PVCs with your stateful set.

When you [dynamically provision your PVCs when creating the stateful set](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storagefile_dynamic_statefulset), the name of the PVC is assigned based on the values that you used in the stateful set YAML file. In order for the stateful set to use existing PVCs, the name of your PVCs must match the name that would automatically be created when using dynamic provisioning.
To establish an inbound VPN connection, modify the following settings.



1. Verify that ipsec.auto is set to add.
2. Optional: Set loadBalancerIP to a portable public IP address for the strongSwan VPN service. Specifying an IP address is useful when you need a stable IP address, such as when you must designate which IP addresses are permitted through an on-premises firewall. The cluster must have at least one available public load balancer IP address. [You can check to see your available public IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-subnetsreview_ip) or [free up a used IP address](https://cloud.ibm.com/docs/containers?topic=containers-subnetsfree).



* If you leave this setting blank, one of the available portable public IP addresses is used.
* You must also configure the public IP address that you select for or the public IP address that is assigned to the cluster VPN endpoint on the on-premises VPN endpoint.





To establish an outbound VPN connection, modify the following settings.



1. Change ipsec.auto to start.
2. Set remote.gateway to the public IP address for the on-premises VPN endpoint in the remote network.
3. Choose one of the following options for the IP address for the cluster VPN endpoint:



* Public IP address of the cluster's private gateway: If your worker nodes are connected to a private VLAN only, then the outbound VPN request is routed through the private gateway to reach the internet. The public IP address of the private gateway is used for the VPN connection.
* Public IP address of the worker node where the strongSwan pod runs: If the worker node where the strongSwan pod runs is connected to a public VLAN, then the worker node's public IP address is used for the VPN connection.



* If the strongSwan pod is deleted and rescheduled onto a different worker node in the cluster, then the public IP address of the VPN changes.