vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information, see [Importing a Knowledge Studio corpus](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-entity-extractorentity-extractor-import-wks).





 Retaining subtype information 

When you import a Knowledge Studio model to Discovery, any subtypes that were defined in the model are identified as mentions of the parent entity type. The subtype entities themselves are not preserved. To retain the subtype information, you must flatten your type system by converting entity subtypes into new root-level entity types.

Follow these steps only if you are sure that the subtype distinctions add significant value to the model. In many use cases, using the root-level entity types is sufficient.

You cannot use this procedure to retain subtypes if any of the documents in your corpus were pre-annotated with the Natural Language Understanding service. Make sure that your flattened type system doesn't surpass the allowed number of entity types for your plan. For more information, see [Entity extractor limits](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-entity-extractorentity-extractor-limits).

For example, your model might have entity types with the following hierarchy:

APPLIANCES
FURNITURE
PATIO
LIVING
DINING

A flattened version of the type sytem looks like this:

APPLIANCES
FURNITURE_NONE
FURNITURE_PATIO
FURNITURE_LIVING
FURNITURE_DINING

A useful approach for flattening the type system involves the following changes:



* Add the parent entity type label (FURNITURE) as a prefix to the label of each child subtype to produce a new root-level entity that preserves the hierarchical relationship in its label. For example, FURNITURE_PATIO, FURNITURE_LIVING, and FURNITURE_DINING.
* Append the word NONE to the parent root-level entity label to identify it as the parent. For example, FURNITURE_NONE.
* Leave the labels of entity types that don't have subtypes unchanged. For example, the label APPLIANCES doesn't change.



To retain entity subtype information, complete the following steps:



1.
For example, if your image file is named image.vhd, the first block device is exported as image-0.vhd. The second block device is exported as image-1.vhd, and so on.
* How do I boot my virtual server instance from an image?

Go to the Device List. Click the virtual server that you want to start from an ISO template. On the Device Details page, select Actions > Boot from Image. For complete steps, refer to [Booting a virtual server instance from an image](https://cloud.ibm.com/docs/image-templates?topic=image-templates-booting-a-vsi-from-an-image).
* Why did IBM Cloud® transition from Advanced Monitoring by Nimsoft to IBM Cloud Monitoring?

IBM Cloud is committed to providing you the highest quality of service and is making the transition to a new monitoring offering. IBM Cloud Monitoring offers an improved customer experience, robust functionality, and customizable dashboards for your resource monitoring needs. For more information, see [IBM Cloud Monitoring](https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-started).
* What benefits does IBM Cloud Monitoring provide?



* A cloud native and container intelligence management system that you can include as part of your IBM Cloud® architecture.
* Provides real-time operational visibility into the performance and health of your applications, IBM services and platforms.
* A visual representation of your infrastructure. IBM Cloud Monitoring automatically collects important metrics such as CPU usage, used and available memory, response times, network latency, and more.
* Offers administrators, DevOps teams, and developers full stack telemetry with advanced features to monitor and troubleshoot, define alters, and design custom dashboards.



* How does IBM Cloud Monitoring pricing work?

IBM Cloud Monitoring offers different pricing plans.



* Light plan
* Graduated Tier plan



For more information about plans and pricing, see [IBM Cloud Monitoring pricing](https://cloud.ibm.com/docs/monitoring?topic=monitoring-pricing_plans).
* How do I install IBM Cloud Monitoring?
Time series data types 

Time series functions operate on a wide variety of special data types that are designed especially for time series data.

Time series data types are binary data types that are especially designed to hold time series data. Alternatively, you can store time series data in any BinaryType data array, such as the ones offered by Parquet, Avro, ORC, or JSON. CSV does not offer a suitable BinaryType data array for storing time series data.



Table 1. Time series data types

 Data type Description 

| DoubleTimeSeries | Time series with univariate observations of type Double. See the following example: [ (1, 7.2), (3, 4.5), (5, 4.5), (5, 4.6), (5, 7.1), (7, 3.9), (9, 1.1) || DoubleArrayTimeSeries | Time series with multivariate observations of type Double. See the following example: (1, 7.2, 8.74]), (3, 4.5, 9.44]), (5, 4.5, 10.12]), (5, 4.6, 12.91]), (5, 7.1, 9.90]), (7, 3.9, 3.76])] || DoubleSegmentTimeSeries | DoubleTimeSeries that is segmented. See the following example: (1,(1, 7.2), (3, 4.5)]), (5,(5, 4.5), (5, 4.6), (5, 7.1)]), (7,(7, 3.9), (9, 1.1)])] || DoubleArraySegmentTimeSeries | DoubleArrayTimeSeries that is segmented.
How you set up high availability differs depending on the infrastructure types and network types:



* For Intel Bare Metal that uses Classic Infrastructure network
* For Intel Virtual Servers that use VPC Infrastructure network (does not currently support SAP NetWeaver high availability or SAP HANA high availability)
* For IBM Power Virtual Servers, on IBM Cloud that use IBM Power Virtual Server Group network
* For VMware that uses Classic Infrastructure network



See the respective topics in the Get Started section for:



* [SAP HANA design considerations for High Availability and Disaster Recovery (HA/DR)](https://cloud.ibm.com/docs/sap?topic=sap-hana-design-considerationshana-ha)
* [SAP HANA backups - Storage impacts on Recovery Time Objective (RTO)](https://cloud.ibm.com/docs/sap?topic=sap-storage-design-considerationsstorage-performance-backup-rto)
* [SAP NetWeaver design considerations for High Availability configuration](https://cloud.ibm.com/docs/sap?topic=sap-netweaver-design-considerationsnetweaver-ha)







 How do I connect my SAP Systems running on IBM Cloud to my on-premises systems? 

You have several connectivity options to create secure connections between your on-premises systems and the IBM Cloud. These options are your responsibility to configure, and IBM Cloud operates the underlying services according to the configuration. For more information see [Connectivity to your SAP system landscape](https://cloud.ibm.com/docs/sap?topic=sap-determine-access).







 Licensing and pricing 



 How does SAP licensing work with the IBM Cloud® for SAP infrastructure-as-a-service? 

The IBM Cloud® SAP-certified infrastructure uses the Bring Your Own License (BYOL) model. This model follows the industry standard of IaaS for SAP workloads and is the same approach that is used for many decades with SAP software.

No IBM Cloud® for SAP portfolio offering contains any SAP licensing.

This arrangement applies to:



* SAP Business Application licenses (for example, SAP S/4HANA, SAP ECC)
* SAP Technical Application licenses (for example, SAP HANA, SAP NetWeaver)
You can make products available only to the users you choose by turning off visibility to the IBM Cloud catalog and adding the products to your private catalogs. Use the following command to turn off visibility of the public catalog to all users in your account.

ibmcloud catalog filter hide-ibm-public-catalog





 Managing access to products for all users by using the CLI 

You can use filters to manage which products in the public catalog are available to all users in your account. For example, you might want to restrict access to third-party products. Or, you might want users to work with a specific software type.

If your account is a parent account in an IBM Cloud enterprise, the filters that you set apply to all child account groups and accounts. For more information, see [Managing products for IBM Cloud enterprise](https://cloud.ibm.com/docs/account?topic=account-catalog-enterprise-restrict).



1. Create a new filter.

ibmcloud catalog filter create [--catalog CATALOG] [--category CATEGORY] [--compliance COMPLIANCE] [--deployment-target TARGET] [--exclude-list LIST] [--include-all ALL] [--include-list LIST] [--offering-format FORMAT] [--pricing-plan PLAN] [--provider PROVIDER] [--release RELEASE] [--type TYPE]

When the --catalog CATALOG command is not specified, the filter is created at the account level.
2. Target an account group by specifying the command option --account-group ACCOUNT GROUP.
3. Update the filter to include or exclude a particular product or products. See the [Catalog management CLI](https://cloud.ibm.com/docs/cli?topic=cli-manage-catalogs-plugincreate-filter) guidance for command options or run the ibmcloud catalog filter options command to retrieve the filter options for each filter category.







 Managing access to products for specific users by using the CLI 

Set filters at a private catalog level for fine-grained control of which products in the public catalog are available only to the users you choose.



1. Create a new filter.
After you finish building your configuration file, initialize the Terraform CLI. For more information, see [Initializing Working Directories](https://www.terraform.io/cli/init).

terraform init
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply











 Creating new accounts 

You can create new accounts within your enterprise. The accounts are created as Pay-As-You-Go accounts, and usage is billed to the enterprise. To create an account, you need an access policy with the Editor or Administrator role on the Enterprise service.



 Creating accounts in the console 



1. From the Enterprise dashboard, click Accounts to view accounts and account groups in the enterprise.
2. In the Accounts section, select Add > Create account.
3. Enter a name for the account that's unique within the enterprise. Because it's one of many accounts, a unique, descriptive name helps you understand the purpose of the account at a glance.
4. If you want to assign a different user as the account owner, enter their IBMid in the Owner field. The account owner has full access to manage the account.
5. If you want to add the account to an account group, select the account group to be its parent. The parent that you choose determines where in the enterprise hierarchy the account exists.
6. Click Create.



After you create the account, the account owner can log in to the account to invite other users and manage their access.





 Creating accounts by using the CLI 



1. If you want to add the account to an account group, find the names and IDs of existing account groups.

ibmcloud enterprise account-groups --recursive
2. Create the account by running the following command.
Verify that at least one version of your product is in the ready state.







 Sharing your product by using the console 

When you share a product with enterprises, users in your account, or account groups, they can create instances of any version that is validated and in the ready state. Versions that are in the draft state are not shared with users. Complete the following steps to share your product:



1. In the IBM Cloud® console, click Manage > Catalogs > Private catalogs.
2. Select the private catalog where your product is located.
3. Select the product that you want to share.
4. Click Actions... > Share.
5. Review the list of affected versions.

If you don't see the version that you want to share, make sure that the version is in the ready state.
6. Select one of the following options:



* Share to this account
* Share to this enterprise or account groups to select the enterprise or specific account groups within the enterprise.
* Share with other enterprises to add IDs for enterprises or account groups in other enterprises that you are assigned Editor role or higher on. This option is used to create an allowlist of other enterprises or account groups to which you want to share your product. You must have the Editor role on the enterprise or account group that you are trying to add. Select Add accounts, enter the enterprise ID, and click Add > Share.



When you share your product with another enterprise, the enterprise is added to a list of IDs that are granted access to your product. This list is also known as the allowlist. Any account that is not included in the allowlist can't access your product.
7. Click Share.







 Sharing your product by using the CLI 

When you share a product with users in your account, enterprise, or account groups, they can create instances of any version that is validated and in the ready state. Versions that are in the draft state are not shared with users.
* UI
* CLI







 Sharing private catalog products in an enterprise 

You can share products in your private catalog with users in your account, account groups within your enterprise, the entire enterprise, and even other enterprises that you have access to. By sharing your product, any user within the account, enterprise, or account groups can create an instance of your product.



 Before you begin 



1. You must be assigned the following access. For more information, see [Assigning users access](https://cloud.ibm.com/docs/account?topic=account-catalog-access).



* Editor role on the Enterprise account management service in the enterprise account.
* Administrator role on the Catalog Management account management service in the same account as your product.



2. Verify that at least one version of your product is in the ready state.







 Sharing your product by using the console 

When you share a product with enterprises, users in your account, or account groups, they can create instances of any version that is validated and in the ready state. Versions that are in the draft state are not shared with users. Complete the following steps to share your product:



1. In the IBM Cloud® console, click Manage > Catalogs > Private catalogs.
2. Select the private catalog where your product is located.
3. Select the product that you want to share.
4. Click Actions... > Share.
5. Review the list of affected versions.

If you don't see the version that you want to share, make sure that the version is in the ready state.
6. Select one of the following options:



* Share to this account
* Share to this enterprise or account groups to select the enterprise or specific account groups within the enterprise.
* Share with other enterprises to add IDs for enterprises or account groups in other enterprises that you are assigned Editor role or higher on. This option is used to create an allowlist of other enterprises or account groups to which you want to share your product. You must have the Editor role on the enterprise or account group that you are trying to add. Select Add accounts, enter the enterprise ID, and click Add > Share.
* Share to this enterprise or account groups to select the enterprise or specific account groups within the enterprise.
* Share with other enterprises to add IDs for enterprises or account groups in other enterprises that you are assigned Editor role or higher on. This option is used to create an allowlist of other enterprises or account groups to which you want to share your product. You must have the Editor role on the enterprise or account group that you are trying to add. Select Add accounts, enter the enterprise ID, and click Add > Share.



When you share your product with another enterprise, the enterprise is added to a list of IDs that are granted access to your product. This list is also known as the allowlist. Any account that is not included in the allowlist can't access your product.
7. Click Share.







 Sharing your product by using the CLI 

When you share a product with users in your account, enterprise, or account groups, they can create instances of any version that is validated and in the ready state. Versions that are in the draft state are not shared with users.

Run the [ibmcloud catalog offering publish enterprise](https://cloud.ibm.com/docs/cli?topic=cli-manage-catalogs-pluginpublish-offering-enterprise) command to share your product to your enterprise:

ibmcloud catalog offering publish enterprise [--catalog CATALOG]

Run the [ibmcloud catalog offering publish allowlist](https://cloud.ibm.com/docs/cli?topic=cli-manage-catalogs-pluginpublish-offering-allowllist) command to share your product to an allowlisted set of accounts:

ibmcloud catalog offering publish allowlist [--catalog CATALOG][--account-ids ACCOUNT-IDS]

The ibmcloud catalog offering publish allowlist command shares your product with stand-alone accounts, enterprises, or account groups based on the IDs listed in the command. You must have Editor role or higher on the other enterprise or enterprise account groups that you add to the list to successfully share the product.
This list is also known as the allowlist. Any account that is not included in the allowlist can't access your product.
7. Click Share.







 Sharing your product by using the CLI 

When you share a product with users in your account, enterprise, or account groups, they can create instances of any version that is validated and in the ready state. Versions that are in the draft state are not shared with users.

Run the [ibmcloud catalog offering publish enterprise](https://cloud.ibm.com/docs/cli?topic=cli-manage-catalogs-pluginpublish-offering-enterprise) command to share your product to your enterprise:

ibmcloud catalog offering publish enterprise [--catalog CATALOG]

Run the [ibmcloud catalog offering publish allowlist](https://cloud.ibm.com/docs/cli?topic=cli-manage-catalogs-pluginpublish-offering-allowllist) command to share your product to an allowlisted set of accounts:

ibmcloud catalog offering publish allowlist [--catalog CATALOG][--account-ids ACCOUNT-IDS]

The ibmcloud catalog offering publish allowlist command shares your product with stand-alone accounts, enterprises, or account groups based on the IDs listed in the command. You must have Editor role or higher on the other enterprise or enterprise account groups that you add to the list to successfully share the product. If you add a stand-alone account that is external to your enterprise, the account is added to your allowlist, but your product isn't shared to that account until you have [publishing approval for your product](https://cloud.ibm.com/docs/sell?topic=sell-sw-publish&interface=uisw-request-approval).
If the built-in users and roles do not suit your environment, [create users and roles](https://docs.mongodb.com/manual/tutorial/manage-users-and-roles/create-a-user-defined-role) directly in MongoDB. The admin user for your deployment has the power to create any role or set of privileges for use on your deployment.

Users and roles that are created directly in MongoDB do not appear in Service Credentials and are not integrated with your IBM Cloud account or [IAM](https://cloud.ibm.com/docs/databases-for-mongodb?topic=cloud-databases-iam).





 The ibm User 

If you use the mongo shell to list the users on your deployment, you might notice a user that is named ibm. The ibm user is the internal root account that manages replication, cluster operations, and other functions that ensure the stability of your deployment. Changing or deleting to the ibm user is not advised and disrupts the stability of your deployment.





 The ops_manager users for MongoDB Enterprise Edition 

The Ops Manager is only available in Databases for MongoDB Enterprise Edition deployments. The ops_manager user type has limited permissions. For more information, see the [Ops Manager documentation](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-for-mongodb-ops-manager).
If the CLI is installed, continue with the next step.
2. Log in to the region in the IBM Cloud where you want to provision the instance. Run the following command: [ibmcloud login](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_login)
3. Set the resource group where you want to provision the instance. Run the following command: [ibmcloud target](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_target)

By default, the default resource group is set.
4. Create the instance. Run the [ibmcloud resource service-instance-create](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_service_instance_create) command:

ibmcloud resource service-instance-create NAME logdna SERVICE_PLAN_NAME LOCATION -p '{"private_endpoints_only": PRIVATE_ENDPOINT}'

Where

NAME is the name of the instance

SERVICE_PLAN_NAME is the type of plan. Valid values are lite, 7-day, 14-day, 30-day.

LOCATION is the region where the logging instance is created. To get the latest list of locations that are available for the IBM Log Analysis service, see [Locations](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-regions).



* PRIVATE_ENDPOINT is either true or false. If true only [private endpoints](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-endpoints) can be used to access the instance.

Unless otherwise specified when provisioning an instance, the default is for the instance to be accessible by both public and private endpoints.



For example, to provision an instance with the 7 days retention plan that can be accessed only by private endpoints, run the following command:
The admin catalog ensures that only approved, tested, and compliant deployable architectures are available to the user. Using a single catalog allows administrators to find and use these deployable architectures easily.
* One catalog to publish IaC related to enterprise administration. Having a single catalog to maintain makes it easier to ensure that the correct set of deployable architectures is exposed and maintained. This includes ensuring that updates to deployable architectures are available and deployed in a timely fashion.
* Centralized access control and monitoring for key Enterprise infrastructure. Placing the catalogs and projects in a centralized account means that only a single set of access policies must be audited to ensure the correct (limited) set of users have access to manipulate this infrastructure.
* Use of projects with trusted profiles also ensures that credentials with the capability to manipulate this fundamental configuration are not directly accessible to users and thus cannot be misused. Projects also ensure configuration governance, making it impossible for a single individual to modify key infrastructure.
* Only one schematics agent is needed.







 Bootstrapping the central administration account 

As Central Administration account is responsible for laying down majority of the enterprise account architecture, the enterprise accounts with IBM Cloud and the Central Administration account must be created first.

Steps to bootstrap the Central Administration Account:



1. Manually create a development and production enterprise based on two freshly created subscription accounts ([docs](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-create-enterprise&interface=ui)).
2. Manually create a child account for centralized administration in the production enterprise ([docs](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-enterprise-add&interface=uicreate-accounts))
3. Onboard deployable architectures for the network and services account and for the central administration account to a private catalog ([docs](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-manifest)). The deployable architecture source can be stored in a private git repo accessible over the public network during the bootstrap procedure.
4.