vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* You must set your account Metadata region primary setting to any of the supported FS validated regions in IBM Cloud. For example, you can set it to us-east.
* You must set your account Permitted target region to the set of FS Validated regions where you operate. For example, you can set it to: us-south,us-east,eu-gb,eu-de. This setting will prevent administrators from creating targets in non-allowed locations.
* You must set your account Private api endpoint only setting to only allow administrators to use private endpoints to manage the Activity Tracker Event Routing configuration.
* You can define 1 or more targets of type cloud-object-storage to store your auditing events.

You cannot define targets of type logdna.

You can define a cloud-object-storage target in any of the permitted regions.
* You must define the Default targets setting to configure up to 2 default targets that are used to route auditing events that are not explicitly managed in the account's routing rules. For example, if you have an enterprise account, you can define 1 target in a different account to route auditing events from any child accounts in your Enterprise, and a local target in the account to keep a copy local to the account.
* You must define 1 route to configure the account to route global auditing events and location-based auditing events.

For example, to capture auditing events across all supported locations in a single target within the account, you can define a route with the following rule:

[
{
"locations":
"global",
"eu-de",
"eu-gb",
"us-south",
"us-east"
],
"target_ids":
"<COS TARGET ID 1>"
]
}
]

For example, to capture auditing events across all supported locations within the account and in a different account, you can define a route with the following rule:

[
{
"locations":
"global",
"eu-de",
"eu-gb",
"us-south",
"us-east"
The response shows that the metadata parameter set to true when you enable the service. You can also verify the metadata service setting by making a GET /instance/{id} call.





 Enable or disable the metadata service when you create new instance templates by using the API 

When you create an instance template, you can set this value by making a POST /instance/templates call. By default, the enabled property is set to false. To enable it, set it to true.

For example,

curl -X POST "$vpc_api_endpoint/v1/instance/templates?version=2022-08-08&generation=2" -H "Authorization: Bearer $iam_token" -d '{
"image": {
"id": "3f9a2d96-830e-4100-9b4c-663225a3f872"
},
"keys": [
{
"id": "363f6d70-0000-0001-0000-00000013b96c"
}
],
"name": "my-instance-template",
"metadata_service": {
"enabled": true
},
"primary_network_interface": {
"subnet": {
"id": "0d933c75-492a-4756-9832-1200585dfa79"
}
},
"profile": {
"name": "bx2-2x8"
},
"vpc": {
"id": "dc201ab2-8536-4904-86a8-084d84582133"
},
"zone": {
"name": "us-south-1"
}
}'

You can't use the API to change the metadata-service setting after the instance template is created. If you disabled it for a template, create a new instance template with the metadata-service enabled set to true.
1. Set up your [API environment](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environmentapi-prerequisites-setup) with the right variables.
2. Store any additional variables to be used in the API commands; for example:



* ResourceGroupId - Find the resource group ID by using the get resource groups command and then populate the variable:

export ResourceGroupId=<your_resourcegroup_id>
* SubnetId - Find the subnet ID by using the get subnet command and then populate the variable:

export SubnetId=<your_subnet_id>



3. When all variables are initiated, create the VPN server:

curl -X POST "$vpc_api_endpoint/v1/vpn_servers?version=$api_version&generation=2" -H "Authorization: $iam_token" -d '{
"certificate": {
"crn": "crn:v1:staging:public:cloudcerts:us-south:a/aa5a471f75bc456fac416bf02c4ba6de:1862b0b4-c1f8-4eef-a6b5-e9c00c9f593d:certificate:6c801ef768c139d986b4c6f91175e8cc"
},
"client_ip_pool": "192.168.50.0/22",
"name": "my-new-vpn-server",
"subnets": [
{
"id": "0716-046c3fd3-1cc5-40f6-b0ad-bbc305308f6d"
},
{
"id": "0726-30ff71ff-3e90-42a9-aa93-96a062081f18"
}
],
"client_authentication": [
{
"method": "certificate",
The response shows that the metadata parameter set to true when you enable the service. You can also verify the metadata service setting by making a GET /instance/{id} call.





 Enable or disable the metadata service when you create new instance templates by using the API 

When you create an instance template, you can set this value by making a POST /instance/templates call. By default, the enabled property is set to false. To enable it, set it to true.

For example,

curl -X POST "$vpc_api_endpoint/v1/instance/templates?version=2022-08-08&generation=2" -H "Authorization: Bearer $iam_token" -d '{
"image": {
"id": "3f9a2d96-830e-4100-9b4c-663225a3f872"
},
"keys": [
{
"id": "363f6d70-0000-0001-0000-00000013b96c"
}
],
"name": "my-instance-template",
"metadata_service": {
"enabled": true
},
"primary_network_interface": {
"subnet": {
"id": "0d933c75-492a-4756-9832-1200585dfa79"
}
},
"profile": {
"name": "bx2-2x8"
},
"vpc": {
"id": "dc201ab2-8536-4904-86a8-084d84582133"
},
"zone": {
"name": "us-south-1"
}
}'
Show more

You can't use the API to change the metadata-service setting after the instance template is created. If you disabled it for a template, create a new instance template with the metadata-service enabled set to true.
You can customize your settings by using the --set option in the helm install command. Depending on the settings that you want to customize, you might need to prepare multiple --set options before you can install the Helm chart. For example, you might want to autoscale your default worker pool by preparing the following --set option. Note: If your default command line shell is zsh, start a bash session before running the following command.

--set workerpools[0].<pool_name>.max=<number_of_workers>,workerpools[0].<pool_name>.min=<number_of_workers>,workerpools[0].<pool_name>.enabled=(true|false)

workerpools[0]
: The first worker pool to enable or disable for autoscaling. You must include three parameters for each worker pool for the command to succeed: the maximum number of worker nodes (max), the minimum number of worker nodes (min), and whether you want to enable (true) or disable (false) autoscaling for this worker pool. To include multiple worker pools, include a comma-separated list and increase the number in brackets, such as: workerpools[0].default...,workerpools[1].pool1...,workerpools[2].pool2....

<pool_name>
: The name or ID of the worker pool that you want to enable or disable for autoscaling. To list available worker pools, run ibmcloud ks worker-pool ls --cluster <cluster_name_or_ID>.

max=<number_of_workers>
: Specify the maximum number of worker nodes per zone that the cluster autoscaler can scale up to. The value must be equal to or greater than the value that you set for the min=<number_of_workers> size.

min=<number_of_workers>
: Specify the minimum number of worker nodes per zone that the cluster autoscaler can scale down to. The value must be 2 or greater so that your ALB pods can be spread for high availability.
Set the CLI region by running [ibmcloud target -r <region>](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_target) command.
* Check that you have the [IAM permissions](https://cloud.ibm.com/docs/schematics?topic=schematics-accessblueprint-permissions) to create an agent policy.
* Create an agent policy target file





 Defining a JSON policy target file 

A sample JSON policy target file is provided here. Replace the <...> placeholders with your actual values.



* The target agent jobs are to be executed on is defined using the target block.
* The assignment parameters for selecting workspace jobs to execute is defined by the parameter block.



Policy JSON files can be edited in any editor or IDE. They must be valid JSON.

Policy JSON file syntax:

{
"target": {
"selector_kind": "ids",
"selector_ids": [
"<agent id>"
]
},
"parameter": {
"agent_assignment_policy_parameter": {
"selector_kind": "scoped",
"selector_scope": [{
"kind": "workspace",
"tags":
"<user_tag>"
],
"resource_groups":
"<resource_group>"
],
"locations":
"<region>"
]
}]
}
}
}

Show more

Example

{
"target": {
"selector_kind": "ids",
"selector_ids": [
"agent-prod-live.deA.e055"
]
},
"parameter": {
"agent_assignment_policy_parameter": {
"selector_kind": "scoped",
"selector_scope": [{
after getting a new access token...
service.get_authenticator().set_bearer_token('54321');

import {
"github.com/IBM/go-sdk-core/v5/core"
"<appropriate-git-repo-url>/exampleservicev1"
}
...
// Create the authenticator.
bearerToken := // ... obtain bearer token value ...
authenticator := &core.BearerTokenAuthenticator{
BearerToken: bearerToken,
}

// Create the service options struct.
options := &exampleservicev1.ExampleServiceV1Options{
Authenticator: authenticator,
}

// Construct the service instance.
service := exampleservicev1.NewExampleServiceV1(options)

// 'service' can now be used to invoke operations.
...
// Later, if your bearer token value expires, you can set a new one like this:
newToken := // ... obtain new bearer token value
authenticator.BearerToken = newToken

const ExampleServiceV1 = require('mysdk/example-service/v1');
const { BearerTokenAuthenticator } = require('mysdk/auth');

const authenticator = new BearerTokenAuthenticator({
bearerToken: '<access-token>',
});

const myService = new ExampleServiceV1({
authenticator,
});
...

// Later when the access token expires, the application must acquire
// a new access token, then set it on the authenticator.
// Subsequent request invocations will include the new access token.
authenticator.setBearerToken('<new-access-token>')
: Set the amount of time after scale up that scale down evaluation resumes. The default value for scaleDownDelayAfterAdd is 10 minutes. The default value is 10m.

scaleDownDelayAfterDelete
: Set the amount of time after node deletion that scale down evaluation resumes. The default value for scaleDownDelayAfterDelete is the same as the scan-interval which is 1m. The default value is 1m.

scaleDownUtilizationThreshold
: Set the worker node utilization threshold. If the worker node utilization goes under the threshold, the worker node is considered to be scaled down. Worker node utilization is calculated as the sum of the CPU and memory resources that are requested by all pods that run on the worker node, divided by the worker node resource capacity. The default value is 0.5.

scanInterval
: Set how often in minutes that the cluster autoscaler scans for workload usage that triggers scaling up or down. The default value is 1m.

expander
: Specify how the cluster autoscaler determines which worker pool to scale if you have multiple worker pools. The default value is random.
: random: Selects randomly between most-pods and least-waste.
: most-pods: Selects the worker pool that is able to schedule the most pods when scaling up. Use this method if you are using nodeSelector to make sure that pods land on specific worker nodes.
: least-waste: Selects the worker pool that has the least unused CPU after scaling up. If two worker pools use the same amount of CPU resources after scaling up, the worker pool with the least unused memory is selected.

ignoreDaemonSetsUtilization
: When set to true, the cluster autoscaler ignores DaemonSet pods when it calculates resource utilization for scale-down. The default value is false.

maxBulkSoftTaintCount
: Set the maximum number of worker nodes that can be tainted or untainted with PreferNoSchedule at the same time. To disable this feature, set to 0. The default value is 0.

maxBulkSoftTaintTime
--env, -e
: Set environment variables for runs of the job. Must be in NAME=VALUE format. This action adds a new environment variable or overrides an existing environment variable. Specify one environment variable per --env option; for example, --env envA=A --env envB=B. This value is optional.

--env-cm, --env-from-configmap
: Set environment variables from the key-value pairs that are stored in this configmap by using one of the following ways:



* To add environment variables for all keys in a configmap that is named configmapName, use the value configmapName. You can modify the environment variable names by specifying a prefix when referencing the configmap. To specify a prefix, use the value PREFIX=CONFIGMAP_NAME. Each resulting environment variable has the format <PREFIX><NAME_OF_KEY_IN_CONFIGMAP>. For example, to set the prefix for all variable names of keys in configmap configmapName to CUSTOM_, use the value CUSTOM_=configmapName. If the configmap configmapName contains KEY_A, the environment variable name is CUSTOM_KEY_A.
* To add environment variables for individual keys, use the format NAME:KEY_A,KEY_B. For example, to add an environment variable for a single key key1 in a configmap that is named configmapName, use the value configmapName:key1. To assign a different name to a referenced key, use the format NAME:NEW_NAME=KEY_A. For example, to add an environment variable named myKey for a single key key1 in a configmap that is named configmapName, use the value configmapName:myKey=key1.



This value is optional.

--env-sec, --env-from-secret
: Set environment variables from the key-value pairs that are stored in a secret by using one of the following ways:
Check the current setting by running the command, - ifconfig| grep -i MTU.
2. Change the current setting to support 9000 MTU by running the command, ifconfig eth0 mtu 9000.
3. Change the setting so that it persists after the system is restarted. Edit the file /etc/network/interfaces, and add MTU=9000.







 Configuring jumbo frames for CentOS and Red Hat Enterprise Linux 

To increase the maximum transmission unit (MTU) to support ethernet jumbo frames if you are running CentOS or Red Hat Enterprise Linux, complete the following steps:



1. Check the current setting by running the command, ip link show dev eth0
2. Change the current setting to support 9000 MTU by running the command, ip link set mtu 9000 dev eth0.
3. Change the setting so that it persists after the system is restarted. Edit the file /etc/sysconfig/network-scripts/ifcfg-eth0, and add MTU=9000.







 Configuring jumbo frames for Windows 

To increase the maximum transmission unit (MTU) to support ethernet jumbo frames if you are running Windows, complete the following steps:



1. Check the current setting by running the command, netsh interface ipv4 show interfaces
2. Change the current setting to support 9000 MTU by running the command, netsh interface ipv4 set subinterface “12” mtu=9000 store=persistent.
* The Set by integration page shows variables that are automatically provided by the integration your customer is using to connect to the assistant. (These variables are not set if no integration is connected.)



Set by assistant:



Variables set by assistant

 Variable name Variable ID Description Examples 

 Digressed from digressed_from Last action before the customer digressed (or null if not digressed) Pay bill 
 Now now The current date and time in the user's time zone. 2021-08-11T11:28:02 
 Current time current_time The current time in the user's time zone. 11:28:02 
 Current date current_date The current date in the user's time zone. 2021-08-11 
 Fallback reason fallback_reason The reason why a user is routed to the fallback action Step validation failed - Agent requested - No action matches 
 No action matches count no_action_matches_count Represents a count of customer's consecutive unrecognized input attempts 3 



Set by integration:



Variables set by integration

 Variable name Variable ID Description Example 

 Timezone timezone The user's time zone as specified by the integration or API client. The default time zone (if not specified by the integration) is Coordinated Universal Time. America/New_York 
 Locale locale The user's locale as set by the integration or API client. The locale can affect understanding and formatting of dates, times, and numbers. en-gb 
 Channel Name channel_name The name of the channel that your user is interacting with. Web chat 









 Storing a value in a session variable 

Any action can store a value in a session variable so it is available to other actions. To store a value in a session variable:



1. From within a step, click Set variable values.
2. Click Set new value.
3. In the Set drop-down list, your choices are:



Set variable values

 Choice Description 

 Session variable The session variable that you want to store the value in. The new value replaces any previous value that is stored. 
 Integration variable The session variable that you want to store the value in.
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







 Step 3: Configure data center VPN and tunnel 



1. The network team at the client data centre will configure an identical IPSec VPN connection with the <DC VPN Public IP> and <VRA Public IP> swapped, the local and remote tunnel address and also the <DC Subnet/CIDR> and <App Zone subnet/CIDR> parameters swapped. The specific configuration commands at the client data center will depend on the vendor of the VPN.
2. Validate that the public IP address of the DC VPN gateway is accessible over the internet before proceeding:

ping <DC VPN Public IP>
3. When data center VPN configuration is complete, the IPSec link should come up automatically. Verify that the link has been established and the status shows that there is one or more active IPsec tunnels. Verify with the data center that both ends of the VPN show active IPsec tunnels.

show vpn ipsec sa
show vpn ipsec status
4. If the link has not been created, validate that the local and remote addresses have been correctly specified and other parameters are as expected using the debug command:

show vpn debug



The line peer-<DC VPN Public IP>-tunnel-1: ESTABLISHED 5 seconds ago, <VRA Public IP>[500]....... should be found in the output. If this does not exist or shows 'CONNECTING' there is an error in the VPN configuration.





 Step 4: Define GRE tunnel 



1. Create the GRE tunnel in VRA edit mode.
First, we'll set up the local environment by ensuring all GO environment variables are set properly. For example:

mkdir $HOME/work
export GOPATH=$HOME/work
export PATH=$PATH:$GOPATH/bin
2. Change path to $GOPATH/src

mkdir $GOPATH/src
cd $GOPATH/src

Now you're ready to start working with the simple Go hello world app.
3. Clone the repository and change to the directory where the sample app is located.

go get github.com/IBM-Cloud/get-started-go
cd github.com/IBM-Cloud/get-started-go
4. Peruse the files in the get-started-go directory to familiarize yourself with the contents.







 Step 2: Run the app locally 



1. Build and run the app locally by running the following commands.

make
go run main.go
2. View your app at the following URL: http://localhost:8080

Press Ctrl-C to stop your app from the same window where you started the app.







 Step 3: Prepare the app for deployment 

To deploy to IBM Cloud, it can be helpful to set up a manifest.yml file. The manifest.yml includes basic information about your app, such as the name, how much memory to allocate for each instance and the route. We've provided a sample manifest.yml file in the get-started-go directory.

Open the manifest.yml file, and change the name from GetStartedGo to your app name, app_name.

apps:
- name: GetStartedGo
random-route: true
memory: 128M
buildpack: go_buildpack

In this manifest.yml file, random-route: true generates a random route for your app to prevent your route from colliding with others. If you choose to, you can replace random-route: true with host: myChosenHostName, supplying a host name of your choice.





 Step 4: Deploy the app
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







 Step 3: Configure data center VPN and tunnel 



1.
--env, -e
: Set environment variables for runs of the job. Must be in NAME=VALUE format. This action adds a new environment variable or overrides an existing environment variable. Specify one environment variable per --env option; for example, --env envA=A --env envB=B. This value is optional.

--env-cm, --env-from-configmap
: Set environment variables from the key-value pairs that are stored in this configmap by using one of the following ways:



* To add environment variables for all keys in a configmap that is named configmapName, use the value configmapName. You can modify the environment variable names by specifying a prefix when referencing the configmap. To specify a prefix, use the value PREFIX=CONFIGMAP_NAME. Each resulting environment variable has the format <PREFIX><NAME_OF_KEY_IN_CONFIGMAP>. For example, to set the prefix for all variable names of keys in configmap configmapName to CUSTOM_, use the value CUSTOM_=configmapName. If the configmap configmapName contains KEY_A, the environment variable name is CUSTOM_KEY_A.
* To add environment variables for individual keys, use the format NAME:KEY_A,KEY_B. For example, to add an environment variable for a single key key1 in a configmap that is named configmapName, use the value configmapName:key1. To assign a different name to a referenced key, use the format NAME:NEW_NAME=KEY_A. For example, to add an environment variable named myKey for a single key key1 in a configmap that is named configmapName, use the value configmapName:myKey=key1.



This value is optional.

--env-from-configmap-rm, --env-cm-rm
: Remove environment variable references to full configmaps by using the configmap name.