vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The account containing the classic infrastructure is then able to view the gateway and all of its connections, and must choose to opt-in to allow account-to-account interconnectivity.
: For more information, see [Adding a cross-account connection](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-adding-cross-account-connections&interface=ui).





 01 January 2021 

Connect networks to multiple local gateways
: You can now connect networks, VPCs, and classic connections to multiple local transit gateways. Previously, you could connect a network only to a single transit gateway. Now traffic between local networks can use a local gateway. In addition, if you need to connect to a remote network, you can attach to a global gateway. Routing of traffic between networks takes an optimized path (if multiple connections exist), meaning local traffic stays local to the region and is not charged.
: The limit for the number of gateways per account has been updated to ten, and the limit of gateways per region to five. You can open an [IBM Support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatarusing-avatar) if you need to expand your service limits further.





 01 July 2020 

VPC connections across IBM Cloud accounts
: You can now connect to a VPC in another IBM Cloud account by providing the CRN of the VPC when adding a connection to your transit gateway. The account containing the VPC is then able to view the gateway and all of its connections, and must choose to opt-in to allow account-to-account interconnectivity for that VPC.
: For more information, see [Adding a cross-account connection](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-adding-cross-account-connections&interface=ui).
Certificate Authorities (CAs) 

You can think of a blockchain network as a series of managed interactions between nodes to serve a defined business use case. For these interactions to be verifiable (to ensure, in other words, who is who) requires identities and a system of permissions that can be checked during each interaction. You can think of the kind of identity that is needed as being similar to a credit card in that it identifies someone within a particular context. Credit cards identify an individual in terms of banking transactions, while Fabric identities allow users to be identified in a blockchain context.

In Hyperledger Fabric, as well as the IBM Blockchain Platform, this component is the Certificate Authority (CA), which creates identities in the form of x509 certificates as well defining of an organization through the creation of a Membership Services Provider (MSP), which defines the permissions of identities at a component and channel level. These identities can include attributes about them, for example, by linking them to a particular organization or organizational unit (OU).

An organization MSP, for example, has an MSP subfolder called admins. Any user whose certificate is inside that admin folder is an admin of the organization. Because this MSP defines the organization, it is listed in the configuration on every channel of which the organization is a member. As a result, whenever an admin of the organization tries to perform an action, the signing certificate of the admin (which is attached to all of its interactions) is checked against the certificates listed in the MSP. Does the certificate match the one listed in the channel configuration? If it does, the other organizations will validate it and the action can be performed. If not, the request to execute the transaction is rejected.

IBM Blockchain Platform CAs are based on the [Hyperledger Fabric CA](https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/), though it is possible to use another CA if it uses a PKI based on x.509 certificates. Because non-Fabric CAs are not configured to create properly formatted MSPs, users who want to use this kind of CA must create the MSP for themselves.
Upgrading from logging agent version 1 to logging agent version 2 

If your Kubernetes cluster version is 1.9+, you can upgrade the logging agent to version 2.

When you upgrade the version of the agent, some logs may not be collected or duplicated depending on the period of time that you take to delete the current logging agent and deploy a new version of the logging agent in the cluster.

Complete the following steps from the command line to upgrade the logging agent version that is deployed in your Kubernetes cluster:



 Step 1. Set the cluster context 



1. Open a terminal to log in to IBM Cloud.

ibmcloud login -a cloud.ibm.com

Select the account where you provisioned the IBM Log Analysis instance.
2. List the clusters to find out in which region and resource group the cluster is available.

ibmcloud ks clusters
3. Set the resource group and region.

ibmcloud target -g RESOURCE_GROUP -r REGION

Where

RESOURCE_GROUP is the name of the resource group where the cluster is available, for example, default.

REGION is the region where the cluster is available, for example, us-south.
4. Set the cluster where you want to configure logging as the context for this session.

ibmcloud ks cluster config --cluster <cluster_name_or_ID>







 Step 2. Backup the YAML file of the logging agent that is deployed in the cluster 

Run the following command to backup the YAML file of the logging agent that is currently deployed in your cluster:

kubectl get ds logdna-agent -o yaml > logdna-agent-<clusterName>-<date>.yaml

Where



* clusterName is the name of your cluster
* date is the current date







 Step 3. Create the namespace ibm-observe 

This step is only required if you installed the logging agent version 1 in a namespace that is different to ibm-observe.

To check if the namespace exists, run the following command:

kubectl get namespaces

Verify the ibm-observe namespace is active.
--size-per-zone NUMBER_WORKERS_PER_ZONE
: Specify the number of worker nodes to create per zone in this worker pool. No worker nodes are created until you [add zones](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_zone-add-vpc-gen2) to the worker pool. This value is required, and must be 2 or greater. For more information, see [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqssmallest_cluster).

--operating-system SYSTEM
: Optional. The operating system of the worker nodes you want to provision in your cluster. For a list of available operating systems by cluster version, see [Red Hat OpenShift on IBM Cloud version information](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions).

--flavor FLAVOR
: Choose a flavor for your worker nodes. You can deploy your worker nodes as virtual machines on shared or dedicated hardware. To see flavors that are available in a VPC zone, run ibmcloud oc flavors --zone <vpc_zone> --provider vpc-gen2.

--vpc-id VPC_ID
: Optional: Specify the ID of the VPC in which to create the worker pool's worker nodes. The value must match the VPC ID that the cluster is in. To list the cluster's VPC ID, run ibmcloud oc cluster get -c <cluster_name_or_ID>. If this option is not provided, then the worker pool defaults to the VPC ID of existing worker pools in the cluster.

-l, --label KEY1=VALUE1
: Optional: Apply key-value labels to each worker node in the worker pool. To specify multiple labels, use multiple options, such as -l key1=value1 -l key2=value2.

--entitlement cloud_pak
* A role helps qualify the entity type in the context in which the mention occurs. For example, the mention Software Engineer might be labeled with the entity type PEOPLE and, in this context, by the role OCCUPATION. See [When to define roles](https://cloud.ibm.com/docs/watson-knowledge-studio-data?topic=watson-knowledge-studio-data-typesystemwks_typesystem_roles) for more information.
* A subtype helps further classify the entity type. For example, the entity type GOVERNMENT might have subtypes of MILITARY and CIVILIAN.



> Note: By defining a role or subtype for an entity, you are giving more options to the person who will associate type information to mentions at annotation time. The human annotator can apply an annotation that specifies the entity type only, or the entity type plus the role or subtype that you are defining now.

Try to define enough entity types to capture the key concepts that you want to annotate, but not so many entity types that it becomes cumbersome for human annotators to apply the labels accurately.
3. Click Mention Classes and Mention Types to view the default mention classes and mention types. You cannot edit these values.

The purpose of an attribute is to help label each mention by the type of thing that it is. A mention type indicates whether the mention is a name, nominal, or pronoun, and a mention class indicates whether the mention is specific, generic, or negated.
4. Open the Assets> Relation Types page and specify how two mentions can relate to each other.

Order between the first and second entities in a relation type is usually relevant. For example, a PERSON entity can be an employee of an ORGANIZATION entity or a geo-political entity (GPE), such as MaryemployedByIBM, but organizations and geo-political entities cannot be employed by a person. When a human annotator clicks an entity in the ground truth editor , the list of available relation types is controlled by what is defined in the type system.

Do not define relation attributes. They are not used by the machine learning model. The model uses only the relation type and order, and ignores the relation attributes.
5.
The request is automatically forwarded by the VPC ALB to one of the node ports on the worker node, and then to the private IP address of the app pod.
3. If app instances are deployed to multiple worker nodes in the cluster, the load balancer routes the requests between the app pods on various worker nodes. Additionally, if you have a multizone cluster, the VPC ALB routes requests to worker nodes across all subnets and zones in your cluster.







 Setting up a Network Load Balancer for VPC 

Expose your app to the public or to the private network by setting up a [public](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaassetup_vpc_nlb_pub) or [private](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaassetup_vpc_nlb_priv) Kubernetes LoadBalancer service in each zone of your VPC cluster. Then, you can optionally [register the VPC NLB with a DNS record and TLS certificate](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaasvpc_nlb_dns).



 Setting up a public VPC NLB 

Expose your app to public network traffic by setting up a Kubernetes LoadBalancer service in each zone of your cluster. When you create the Kubernetes LoadBalancer service, a public Network Load Balancer for VPC (VPC NLB) that routes requests to your app is automatically created for you in your VPC outside of your cluster.



* Ensure that you have the [Writer or Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the namespace in which you deploy the Kubernetes LoadBalancer service for the VPC NLB.
* [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)
For example, you might have an array of objects containing city names and their population numbers:

[
{
"name":"Tokyo",
"population":13988129

},
{
"name":"Rome",
"population":2860009

},
{
"name":"Beijing",
"population":21893095

},
{
"name":"Paris",
"population":2165423

}
]
Show more

If the source array is stored in a variable called ${cities}, the following exexpression returns a smaller array that contains only cities with populations greater than 5 million:

${cities}.filter("city", "city.population > 5000000")

The expression returns the following filtered array:

[
{
"name":"Tokyo",
"population":13988129

},
{
"name":"Beijing",
"population":21893095

}
]

Instead of a hardcoded comparison value, you could also filter based on a dynamic value stored in a variable. This example filters using a population value specified by a customer response in a previous step:

${cities}.filter("city", "city.population > ${step_123}")

When comparing number values, be sure to set the context variable involved in the comparison to a valid value before the filter method is triggered. Note that null can be a valid value if the array element you are comparing it against might contain it.







 Array.get(Integer index) 

This method returns the item from the array that is at the specified index position. Note that arrays are zero-indexed, meaning that the first item in the array is at index position 0.

${Items}.get(1)

If Items is ['one', 'two', 'three'], this example returns two.

The get() method is an alternative to using brackets ([]) to retrieve an item from an array.
You will need this information for [Step 6](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-upgrade_log_analysis_agent_3upgrade_log_analysis_agent_3_step6).

Do not use the latest or stable versions.

The [LogDNA release notes](https://docs.mezmo.com/changelog) lists all LogDNA enhancements and fixes, including enhancements and fixes to the LogDNA Agent.





 Step 2. Set the cluster context 



1. Open a terminal to log in to IBM Cloud.

ibmcloud login -a cloud.ibm.com
2. List the clusters to find out in which region and resource group the cluster is available.

ibmcloud ks clusters
3. Set the resource group and region.

ibmcloud target -g RESOURCE_GROUP -r REGION

Where

RESOURCE_GROUP is the name of the resource group where the cluster is available, for example, default.

REGION is the region where the cluster is available, for example, us-south.
4. Set the cluster where you want to configure logging as the context for this session.

ibmcloud ks cluster config --cluster <cluster_name_or_ID>







 Step 3. Backup the YAML file of the logging agent that is deployed in the cluster 

Run the following command to backup the YAML file of the logging agent that is currently deployed in your cluster:

kubectl get ds logdna-agent -o yaml --namespace=<namespace> > logdna-agent-<clusterName>-<date>.yaml

Where



* clusterName is the name of your cluster
* date is the current date
* namespace is the namespace where you deployed your agent. This is normally ibm-observe.







 Step 4. Create the namespace ibm-observe 

This step is only required if you installed the prior logging agent in a namespace that is different from ibm-observe.

To check if the namespace exists, run the following command:

kubectl get namespaces
When you create the Kubernetes LoadBalancer service, a private Network Load Balancer for VPC (VPC NLB) that routes requests to your app is automatically created for you in your VPC outside of your cluster.

Before you begin



* Ensure that you have the [Writer or Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the namespace in which you deploy the Kubernetes LoadBalancer service for the VPC NLB.
* Connect to your VPC private network, such as through a [VPC VPN connection](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaas).
* [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)
* To view VPC NLBs, install the infrastructure-service plug-in. The prefix for running commands is ibmcloud is.

ibmcloud plugin install infrastructure-service





* When cluster nodes are reloaded or when a cluster master update includes a new keepalived image, the load balancer virtual IP is moved to the network interface of a new node. When this occurs, any long-lasting connections to your load balancer must be re-established. Consider including retry logic in your application so that attempts to re-establish the connection are made quickly.



To enable your app to receive private network requests,



1. Create a VPC subnet that is dedicated to your VPC NLB. This subnet must exist in the same VPC and location as your cluster, but can't be attached to your cluster or any worker nodes.



1. From the [VPC subnet dashboard](https://cloud.ibm.com/vpc/network/subnets), click New subnet.
2. Enter a name for your subnet.
3. Select the location where your cluster exists and the zone where you want to create the VPC NLB.
4.
See the [Default field labels](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-configuring-fieldssdu-default-fields) table for a list of the fields and their descriptions.
3. To create a custom field label, click Create new.



* Specify a field label with no spaces. For example, complex_task is a valid field label.

Avoid using a field label name or including characters, such as a number sign (#) or period (.), in the name that have special meaning for Discovery. For more information, see [How fields are handled](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-index-overviewfield-name-limits).
* If you want to change the color that is used to represent the field, repeatedly click the color block ![Square block of color with two arrows that point in a circle](https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/discovery-data/images/sdu-label-color.png) until it is displayed in the color that you want to use.

You cannot change the field label color later.
* Click Create.



4. First, click a field label to activate it.
5. Next, click the block that represents the content that you want to label as the field type.

The block changes to the color of the field label. You successfully labeled the field!
6. Repeat this process to annotate more fields in the document.

Don't worry. You don't need to label every page. As you apply labels and submit pages, Watson learns from what you annotate and starts to predict annotations.

Follow these guidelines:



* If there's nothing special about a section, leave it labeled as text, which is applied by default.
* A label cannot span multiple pages.
* Do not treat bold, italic, or underlined text differently.
Result if it is 2:19 PM: 6 hours ago was 8:19 AM.



 Working with time spans 

To show a response based on whether today's date falls within a certain time frame, you can use a combination of time-related methods. For example, if you run a special offer during the holiday season every year, you can check whether today's date falls between November 25 and December 24 of this year. First, define the dates of interest as context variables.

In the following start and end date context variable expressions, the date is being constructed by concatenating the dynamically-derived current year value with hard-coded month and day values.

"context": {
"end_date": "<? now().reformatDateTime('Y') + '-12-24' ?>",
"start_date": "<? now().reformatDateTime('Y') + '-11-25' ?>"
}

In the response condition, you can indicate that you want to show the response only if the current date falls between the start and end dates that you defined as context variables.

now().after($start_date) && now().before($end_date)





 java.util.Date support 

In addition to the built-in methods, you can use standard methods of the java.util.Date class.

To get the date of the day that falls a week from today, you can use the following syntax.

{
"context": {
"week_from_today": "<? new Date(new Date().getTime() +
(7 * (2460601000L))) ?>"
}
}

This expression first gets the current date in milliseconds (since January 1, 1970, 00:00:00 GMT). It also calculates the number of milliseconds in 7 days. (The (2460601000L) represents one day in milliseconds.) It then adds 7 days to the current date. The result is the full date of the day that falls a week from today.
Mentions of a date or time that are relative to the current time are resolved for a chosen time zone. By default, the time zone is Greenwich mean time. Therefore, REST API clients that are located in different time zones get the current Coordinated Universal Time when now is mentioned in input.

Optionally, the REST API client can add the local time zone as the context variable $timezone. This context variable must be sent with every client request. For example, the $timezone value can be America/Los_Angeles, EST, or UTC. For a full list of supported time zones, see [Supported time zones](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-time-zones).

When the $timezone variable is provided, the values of relative @sys-date and @sys-time mentions are computed based on the client time zone instead of UTC.

For information about processing date and time values, see the [Date and time method reference](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-dialog-methodsdialog-methods-date-time).







 @sys-number entity 

The @sys-number system entity detects mentions of numbers in user input. The number can be written with either numerals or words. In either case, a number is returned.



 Recognized formats 



* 21
* twenty one
* 3.13







 Attributes 



* .literal: Exact phrase in input that is interpreted to be the number.
* .location: Index element values of the first and last letters in the text string that is interpreted to be a number.
* .numeric_value: Canonical numeric value as an integer or a double.
* .range_link: If present, indicates that the user's input contains a number range. The location value of the text that specifies the range is appended to the link name. Additional information is provided, including the role that each @sys-number plays in the range relationship. For example, the start number has a role type of number_from and the end number has a role type of number_to.
Mentions of a date or time that are relative to the current time are resolved for a chosen time zone. By default, the time zone is Greenwich mean time. Therefore, REST API clients that are located in different time zones get the current Coordinated Universal Time when now is mentioned in input.

Optionally, the REST API client can add the local time zone as the context variable $timezone. This context variable must be sent with every client request. For example, the $timezone value can be America/Los_Angeles, EST, or UTC. For a full list of supported time zones, see [Supported time zones](https://cloud.ibm.com/docs/assistant?topic=assistant-time-zones).

When the $timezone variable is provided, the values of relative @sys-date and @sys-time mentions are computed based on the client time zone instead of UTC.

For information about processing date and time values, see the [Date and time method reference](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-methodsdialog-methods-date-time).







 @sys-number entity 

The @sys-number system entity detects mentions of numbers in user input. The number can be written with either numerals or words. In either case, a number is returned.



 Recognized formats 



* 21
* twenty one
* 3.13







 Attributes 



* .literal: Exact phrase in input that is interpreted to be the number.
* .location: Index element values of the first and last letters in the text string that is interpreted to be a number.
* .numeric_value: Canonical numeric value as an integer or a double.
* .range_link: If present, indicates that the user's input contains a number range. The location value of the text that specifies the range is appended to the link name. Additional information is provided, including the role that each @sys-number plays in the range relationship. For example, the start number has a role type of number_from and the end number has a role type of number_to.